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ABSTRACT 


This  thesis  represents  a  cross  Systems  Command  (NAVSEA/NAVAIR) 
developed  product.  The  product  -  the  Sunset  Supply  Base  (SSB)  system  -  provides  a 
complete  system  for  addressing  the  risks  and  supportability  issues  involved  with 
Commercial  Off  the  Shelf  (COTS)  products  in  Navy  combat  and  support  systems.  The 
SSB  system  was  implemented  on  three  Navy  combat  weapon  systems  at  various  phases 
of  the  product  development  life  cycle.  The  main  body  provides  to  the  Program 
Management  Offices  (PMO)  and  other  decision  makers,  a  high  level  summary  of 
performance  expectations.  Appendix  A  -  The  Sunset  Supply  Base  Architecture  - 
identifies  at  a  high  level  of  abstraction  a  collaborative  architecture  providing  a  roadmap 
for  design  and  development  of  the  SSB  system.  Appendix  B  -  The  Systems  Engineering 
Development  and  Implementation  (SEDI)  plan  -  is  a  prescriptive  or  “How  to”  manual 
describing  activities  that  have  been  used  to  successfully  implement  the  SSB  system. 
Appendix  C  -  Business  Case  Analysis  (BCA)  -  presents  the  data  collected  as  a  result  of 
SEDI  plan  implementation  then  addresses  the  business/programmatic  attributes  showing 
the  viability  and  value  proposition  possible  through  the  SSB  system.  Appendix  D  -  The 
Marketing  Plan  for  the  SSB  system  -  defines  methods  and  practices  necessary  to  establish 
the  SSB  system  as  the  alternative  of  choice. 
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EXECUTIVE  SUMMARY 


This  thesis  as  the  “Capstone”  requirement  for  the  PD-21  Masters  program 
perpetuates  the  emphasis  of  the  program  in  providing  the  appropriate  tools  necessary  in 
development  of  a  product  -  “taking  a  light  bulb  idea  and  making  a  real  product  that 
works  for  the  intended  purpose.”  This  thesis  represents  a  cross  Systems  Command 
(NAVSEA/NAVAIR)  developed  product.  The  product  -  the  Sunset  Supply  Base  system 
-  encapsulated  in  the  five  parts  of  this  thesis  paper,  provides  a  complete  system  for 
addressing  the  risks  and  supportability  issues  involved  with  Commercial  Off  the  Shelf 
(COTS)  products  in  Navy  combat  and  support  systems.  In  addressing  the  COTS 
challenges  -  Head-on  -  the  infonnation  contained  herein  was  implemented  on  three  Navy 
combat  weapon  systems  at  various  phases  of  the  product  development  life  cycle: 
AN/ASQ-20X  Sonar  Mine  Detecting  Set  (E&MD  transferring  to  production),  SSDS  MKI 
Ships  Self  Defense  System  (a  legacy  system),  and  SSDS  MKII  Ships  Self  Defense 
System  (current  production). 

The  thesis  body  and  each  of  the  four  appendixes  (A  -  D)  are  written  as  standalone 
documents  addressing  specific  functional  areas  regarding  the  SSB  system.  The  main 
body  of  the  thesis  describes  the  background,  challenges,  and  issues  that  are  addressed  due 
to  COTS  products  in  Navy  systems  then  presents  extracted  highlights  from  the  four 
appendixes  to  illustrate  the  approach,  systematic  methodologies  employed,  and 
subsequent  results  yielded  through  the  implementation  of  the  SSB  system.  It  also 
provides  to  the  Program  Management  Offices  (PMO),  PMO  support  groups,  and  other 
decision  makers  a  high  level  summary  of  perfonnance  expectations. 

Appendix  A  -  The  Sunset  Supply  Base  Architecture  -  identifies  at  a  high  level  of 

abstraction  a  collaborative  architecture  to  provide  a  roadmap  for  design  and  development 

of  the  SSB  system,  which  will  meet  the  Navy’s  needs.  Appendix  B  -  The  Systems 

Engineering  Development  and  Implementation  (SEDI)  plan  for  the  SSB  system  -  is  a 

prescriptive  or  “How  to”  manual  to  enable  implementation  activities  with  processes, 

methods,  tools,  and  practices  that  have  been  used  to  successfully  implement  the  SSB 

system.  The  SEDI  plan  takes  a  Systems  Engineering  approach  leveraging  internal  Navy 

xvii 


resources  and  the  supporting  COTS  supply  base  then  matches  these  resources  to  the 
PMO’s  needs  and  existing  DoD  infrastructure  (i.e.  PPBS,  supply  system.  Fleet 
requirements).  Appendix  C  -  Business  Case  Analysis  (BCA)  -  presents  the  data 
collected  as  a  result  of  implementing  the  SSB  system  as  described  in  the  SEDI  plan  and 
communicates  in  tabular  and  graphical  methods  the  information  and  knowledge  gained. 
The  BCA  addresses  the  business  and  programmatic  attributes  showing  the  viability  and 
value  proposition  possible  through  the  SSB  system.  Appendix  D  -  The  Marketing  Plan 
for  the  SSB  system  -  identifies  the  internal,  external,  and  customer  environments  and 
defines  methods  and  practices  necessary  to  establish  the  SSB  system  as  the  alternative  of 
choice  providing  the  Navy  “best  value”  regarding  the  supportability  of  COTS  products  in 
the  Fleet 
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I.  INTRODUCTION 


A.  BACKGROUND 

Over  the  years  the  Department  of  Defense  (DoD)  has  been  plagued  with 
development  programs  that  have  experienced  significant  cost  overruns  and  schedules  that 
have  slid  to  the  right  all  too  often.  In  the  end,  the  delivered  weapon  systems  prove  to  be 
of  little  value  due  to  the  enormous  delay  of  deploying  them.  The  challenge  to  design, 
develop  and  implement  processes  to  address  these  issues  is  an  ongoing  initiative.  Making 
government  more  efficient  has  been  a  continuous  theme  for  years  now.  In  fact,  as  early 
as  1980  Congress  passed  the  Paperwork  Reduction  Act  in  a  step  towards  improving 
government  performance.  In  1993  the  Government  Performance  and  Results  Act,  which 
required  government  agencies  to  set  strategic  goals,  measure  performance,  and  report  on 
the  degree  to  which  goals  were  met.[l)  NIH]  More  recently,  in  1996,  Congress  passed 
the  Infonnation  Technology  Management  and  Reform  Act  [2)  Clinger-Cohen].  This  act 
essentially  required  government  agencies  to  improve  the  way  they  selected  and  managed 
Information  Technology  (IT)  projects.  Soon  after,  the  Office  of  Management  and  Budget 
(OMB)  established  circular  A-130,  Management  of  Federal  Information  Resources.  The 
purpose  of  this  circular  was  to  further  establish  a  policy  for  managing  Federal 
Information  Resources. [3)  OMB].  The  result  of  the  Clinger-Cohen  Act  and  OMB 
Circular  A-130  was  the  establishment  of  a  comprehensive  approach  by  individual  federal 
agencies  to  improve  the  acquisition  and  management  of  their  IT  development  efforts. 
Working  within  this  new  process,  program  offices  began  aligning  their  resources  in 
support  of  their  respective  strategic  missions.  To  be  effective  they  began  to  implement 
investment  management  strategies  that  established  control  mechanisms  that  would  align 
the  appropriation  of  funds  to  their  strategic  mission.  In  effect,  they  improved  the  way 
they  selected,  planned  and  managed  their  development  programs  by  restructuring  the  way 
they  allocated  their  resources  before  any  initial  investment  was  made  in  a  particular 
program.  One  of  the  ways  these  agencies  achieved  this  was  rethinking  the  selection 
process.  Traditionally,  priorities  were  given  to  their  programs  and  decisions  on  which 
programs  would  be  funded  were  made  based  on  this  prioritization.  Under  this  new  way 
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of  thinking,  the  selection  process  was  centered  on  a  program’s  cost,  benefit  and  risk 
assessments.  These  three  elements  would  be  quantified  and  analyzed  prior  to  any  release 
of  funds.  In  essence,  a  Business  Case  Analysis  (BCA)  was  performed  as  part  of  the 
selection  process. 

In  an  effort  to  provide  “best-value”  in  acquiring  new  weapon  systems  or 
upgrading  existing  platfonns,  the  DoD  sought  to  establish  specific  guidance  to  the 
Program  Management  Offices  (PMO)  for  reducing  life  cycle  costs.  One  of  these 
initiatives  was  the  use  of  Commercial  off  the  shelf  (COTS)  products  and  services.  The 
COTS  Initiative  was  brought  about  by  the  fact  that  the  commercial  sector  essentially 
drives  technology  change  at  an  extremely  fast  pace  and  that  the  DoD  could  take 
advantage  of  this  while  reducing  life  cycle  costs.  The  COTS  Initiative  provided  a 
potential  path  to  infuse  new  technology  into  the  military  systems  and  at  the  same  time 
avoid  the  developmental  costs  associated  with  grooming  the  new  technology.  The  rate  at 
which  private  industry  can  develop  and  deliver  new  technologies  is  orders  of  magnitudes 
faster  than  traditional  DoD  acquisitions. 

The  use  of  COTS  products  in  military  weapon  systems  is  a  reality.  DoD  5000.2 
and  the  Federal  Acquisition  Regulations  (FAR)  have  both  advocated  the  use  of  COTS 
products  due  to  the  potential  benefits  associated  with  leveraging  big  business  capabilities. 
These  capabilities  include  developing  state-of-the-art  technologies  and  delivering  them  in 
products  that  are  produced  in  quantities  that  reduce  cost.  To  this  end,  the  COTS 
manufacturers’  position  in  the  marketplace,  the  company  size  and  its  technology  edge, 
impact  the  direction  and  update  cycles  of  technology  and  the  products  that  employ  them. 
Therefore,  they  hold  a  significant  place  in  weapon  system  development  and 
manufacturing  because  they  can  effectively  facilitate  the  quick  response  to  DoD  changing 
needs.  The  net  result  to  the  DoD  is  a  reduction  in  initial  costs  for  COTS  products  as  well 
as  improved  reliability  and  availability  of  the  weapon  system.  However,  since  military 
weapon  systems  are  typically  unique,  the  use  of  COTS  becomes  a  tricky  business  in 
tenns  of  dictating  system  design  and  ultimately  life  cycle  support.  In  tenns  of  software, 
military  applications  tend  to  be  very  specific,  and  the  weapon  system  cannot  tolerate  or 
support  changes  without  adequate  response  time.  Compatibility  and  configuration- 
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control  become  crucial  elements  for  both  software  and  hardware  due  to  their 
interdependency.  Support  activities  are  pressured  to  maintain  stabilized  baselines  in 
order  to  keep  the  certification  of  the  system  verifiable.  These  baselines  include  not  only 
the  initial  integration  site  but  also  the  interoperability  of  fielded  systems  subsequent  to 
changes  (i.e.,  installation  of  replacement  parts,  firmware,  software  or  hardware  revisions, 
etc...).  Needless  to  say  there  are  significant  risks  associated  with  COTS  and  therefore 
managing  these  risks  is  a  crucial  element  for  success.  For  weapon  systems  that  do  use 
COTS  products  some  of  the  more  identifiable  risks  are: 

•  Engineering  changes,  increased  costs,  and  potential  schedule  delays  due  to 
poor  supportability  late  in  the  development  or  after  fielding  the  system. 

•  Life  cycle  costs  estimates  for  COTS  product  usage  is  inaccurate  due  to  poor 
logistical  support  analysis. 

•  Poor  sustainability  due  to  not  considering  supportability  during  the  design 
phase. 

[4)  DAU] 

Understanding  these  risks  helps  us  to  better  define  where  the  problem  lies.  With 
the  problem  description  provided  above,  we  can  conclude  that  additional  supportability 
solution  alternatives  are  needed  to  address  the  shortcomings  of  the  present  COTS 
environment.  A  proactive  position  must  be  taken  to  include  these  alternatives  in  strategic 
supportability  planning  that  will  effectively  mitigate  the  risks  associated  with  COTS 
product  usage  in  military  weapon  systems. 

This  document  introduces  and  defines  a  support  solution  alternative  that 
specifically  addresses  these  shortcomings.  This  solution  alternative  is  known  as  the 
Sunset  Supply  Base  system..  The  Sunset  Supply  Base  (SSB)  system  is  a  unique 
alternative  approach  to  extend  the  supportability  of  COTS  products  predicated  on  the 
needs  of  the  Navy  Programs.  The  extension  of  product  availability,  beyond  the  Original 
Equipment  Manufacturer  (OEM)  assigned  date  to  drop  the  products  as  obsolete  items, 
provides  stability  to  the  system  baseline  configuration,  during  periods  of  time  between 
scheduled  Technical  Refresh  and  Insertion.  The  uniqueness  of  the  SSB  system  is  evident 
through  how  it  is  structured.  The  OEMs  are:  a)  market  driven,  b)  high  volume  and  high 
technology,  c)  their  business  plan  is  driven  by  their  commercial  customer  base,  with  only 
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about  0.4  %  of  their  business  going  to  DoD  and  d)  Experience  fast  update  cycles  (<  18 
months).  In  contrast  to  these  OEM  attributes,  DoD  has:  1)  Unique  applications  with 
lengthy  life  cycles  (20-40  years),  2)  requires  a  minimum  technology  refresh  or  update 
cycle  of  not  less  than  5  years,  and  3)  have  operational  readiness  and  maintainability 
support  issue  that  span  the  entire  life  cycle.  To  bridge  the  gap  between  the  OEM 
business  planning  and  the  Navy’s  need  for  long-term  support,  the  OEM  is  given 
incentives  to  continue  production  and  if  necessary  a  third  party  is  brought  in.  This  third 
party  is  the  Sunset  Supplier.  The  Sunset  Supplier  makes  a  contractual  relationship  with 
the  OEM  to  produce  the  obsolete  products  for  the  OEM  customer  base.  The  OEM 
transfers  the  intellectual  property  and  assembly  know-how  to  the  Sunset  Supplier  and  for 
this  the  OEM  receives  royalty  on  the  sale  of  all  products  produced.  Internal  to  the  Navy 
are  support  infrastructures  to  ensure  supportability  of  Sunset  products  by  mitigating  any 
component  part  obsolescence  issues  if  they  exist  on  those  products.  The  infrastructure 
and  support  of  the  SSB  process  yields,  not  only,  significant  cost  savings  but  also  provides 
other  benefits,  such  as:  why  don’t  the  #’s  start  with  1? 

1)  Supportability  of  products  defined  by  customer  need,  (5,  10,  15,  20  years) 

2)  Life  Cycle  Cost  (LCC)  savings,  due  to  no  life-time  buy  at  the  assembly  level  is 
needed,  so  the  assemblies  are  procured  as  the  customer  require  them. 

3)  Reparability  of  assemblies  over  the  designated  life  cycle  (5,  10,  15,  20  years) 

4)  Hardware/software/firmware  stability  between  Technology  Refresh 
(TR)/insertion  cycles 

5)  Significant  reduction  in  Program  risk  as  related  to  COTS  and  life  cycle 
management 

6)  Improved  schedule  flexibility  and  support  options  that  can  be  tailored  for  Fleet 
needs 

7)  Minimal  or  no  impact  on  system  operational  performance.  The  performance 
will  remain  constant  through  the  use  of  exactly  the  same  part:  fonn,  fit,  and 
function  replacement,  which  has  been  made  by  the  alternate  manufacturer,  the 
Sunset  Supplier. 

B.  PURPOSE 

1.  General 

The  focus  of  this  document  is  to  present  and  discuss  the  characteristics  of  the 
Sunset  Supply  Base  system  as  it  applies  to  the  acquisition  of  military  weapon  and  support 
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systems.  By  identifying  the  current  status  of  economic  and  sustainment  problems  with 
COTS  product  usage,  we  can  essentially  offer  and  subsequently  evaluate  the  Sunset 
Supply  Base  infrastructure  as  an  alternative  support  solution  to  the  obsolescence  issues 
involving  COTS  products.  To  this  end,  this  document  offers  a  system-architecture,  a 
process  implementation  plan,  a  business  case  analysis  and  finally  a  marketing  plan,  which 
collectively  evaluates  the  feasibility,  effectiveness,  usefulness  and  challenges  to  and  for 
DoD  acceptance.  Each  is  provided  as  a  separate  enclosure  and  can  be  used  independently 
from  the  other  enclosures  for  purposes  tailored  to  specific  reader  needs.  In  reading  any  of 
the  four  deliverables,  it  is  important  to  understand  the  purpose  of  the  SSB  process. 

2.  SSB  Purpose 

The  overall  purpose  of  the  SSB  is  to  provide  dependable,  cost  effective 
supportability  insurance  for  COTS  based  weapon  and  support  systems.  The  result  will 
provide  a  solution  to  COTS  obsolescence  issues,  material  shortages  issues,  and  extend  the 
supportability  of  COTS  components.  The  architecture  should  address  COTS  technology 
obsolescence  management  through  product  and  technology  obsolescence  forecasting 
methodologies  and  provide  a  new  process  for  managing  changes  with  COTS  based 
systems.  The  final  architecture  should  respond  to  the  voice  of  the  customer,  who  is 
demanding  credible  combat  power  through  design  and  supportability,  by  putting  speed 
and  agility  into  the  process,  and  ultimately  provide  some  value  as  perceived  by  the 
customers.  To  be  successful,  the  SSB  process  has  defined  specific  goals  and  objectives 
derived  from  the  present  COTS  product  supportability  inadequacies.  Furthermore,  this 
effort  describes  and  discusses  general  DoD  acquisition  objectives  and  mandates.  In  the 
end  we  can  effectively  propose,  execute  and  evaluate  the  SSB  implementation  against 
substantial  and  appropriate  criteria. 

Ultimately,  the  SSB  architecture  exists  to  respond  to  the  demands  of  the 
warfighter.  The  warfighter  requirements  are  communicated  to  the  program  office,  and 
the  PMO  is  tasked  to  develop  and  support  systems  that  provide  the  expected  combat 
power.  As  part  of  the  Systems  Engineering  approach  employed  through  the  SSB  system 
the  program  managers  develop  a  support  strategy  that  accommodates  the  warfighter 
requirements.  The  SSB  architecture  offers  a  support  alternative  that,  when  implemented 
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as  part  of  the  support  strategy,  adds  speed  and  agility  into  the  supportability  process, 
ultimately  providing  value  as  perceived  by  the  warfighter. 

C.  RESEARCH  QUESTIONS 

1.  Area  of  Research 

The  purpose  of  this  research  is  to  define,  document,  pilot  and  implement  a  support 
system  for  Navy  hardware  that  incorporates  the  use  of  Commercial  Off  The  Shelf 
(COTS)  products.  This  Thesis  provides  a  set  of  transportable/transferable  tools,  methods, 
and  processes  and,  when  taken  in  whole,  will  represent  a  reusable  product.  Identified 
within  the  body  or  as  appendices  shall  be  four  deliverables:  Systems  Architecture  model, 
Systems  Engineering  Development  and  Implementation  (SEDI)plan,  Business  Case 
Analysis  (BCA),  and  Marketing  Plan.  The  documents  (i.e.  deliverables)  will  be 
iteratively  and  recursively  developed  in  parallel  with  the  piloting  of  these  concepts  on 
three  programs.  The  end  result  will  represent  a  useable  product,  already  tested  and 
refined  on  three  Navy  programs. 

2.  Research  Questions 

1)  What  are  the  current  COTS  supportability  methods,  processes,  and  tools? 

2)  Are  those  supporting  efforts  effective  in  meeting  the  Navy’s  needs? 

3)  Can  long  term  supportability  of  COTS  be  realized? 

4)  Does  the  Navy  have  current  systems  that  can  be  leveraged  to  better  support 
COTS? 

5)  What  are  the  real,  root  causes  of  the  COTS  supportability  issue,  If  there  are 
any? 

6)  Can  the  COTS  issues  be  addressed  with  minimal  impact  to  other  functions  and 
systems? 

7)  Can  a  fiscally  responsible  solution  be  identified,  measured,  and  tracked? 

8)  What  resources,  internal  and  external  to  the  Navy  will  be  required  and  at  what 
price? 

9)  Is  there  a  compelling  business  case  for  developing  a  long  term  COTS 
supportability  solution?  If  one  could  be  developed,  how  would  it  be  sustained 
and  verified? 

10)  If  such  a  solution  were  developed  what  methods  or  means  could  be  used  to 
market  it  to  the  other  potential  users  in  the  Navy  or  even  external  to  the  industry 
in  general? 
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1 1)  Is  this  solution  in  concert  with  Acquisition  Reform  (AR),  the  5000  series 
documents,  and  other  DoD  and  Navy  initiatives? 

12)  What  is  the  effect  of  this  new  resolution  system  having  on  Total  Ownership 
Cost  (TOC)? 

13)  Can  the  impact  to  the  using  community  (i.e.  customers)  be  reasonably 
estimated? 

3.  Discussion 

The  subject  under  consideration  is  an  old  initiative,  which  was  ushered  in  at  the 
beginning  of  Acquisition  Refonn  (AR)  and  has  affected  nearly  all  procurements  of 
military  hardware.  The  initiative  is  the  use  of  Commercial  Off  The  Shelf  /Non 
developmental  Items  (COTS/NDI)  /  products  where  possible  in  lieu  of  custom  military 
unique  products.  One  would  expect  that,  after  over  10  years  of  experience  with  living 
with  this  initiative  and  especially  since  it  is  deeply  imbedded  in  policy,  reviewing  criteria, 
and  procurement  methodologies,  that  issues  or  unintended  consequences  as  a  result  of  the 
initiative  would  be  resolved.  However,  with  the  long  development  cycles  and  time 
consuming  implementation  efforts  regarding  military  systems,  the  effects  of 
implementing  the  COTS/NDI  initiative  have  finally  started  to  show  the  “cause  and 
effect”  relationship  between  COTS/NDI  and  perturbations  evident  in  fielded  systems. 
The  Defense  Acquisition  Deskbook  (DAD)  provides  over  230  listings,  as  of  April  2002, 
when  searched  on  COTS/NDI  covering  such  areas  as:  policy,  planning,  designing, 
fielding,  costing,  life  cycle  support,  and  many  others.  The  new  release  of  DoD  5000.2-R 
has  tried  to  address  some  of  the  major  problematic  areas,  thereby  providing  a  few  lessons 
learned.  Specifically  the  areas  of  interoperability,  testing  &  evaluation,  and  even  a 
dedicated  section,  paragraph  C5.2.3.5.7  “Commercial,  Off-the-Shelf  (COTS) 
Considerations”,  are  incorporated  to  help  guide  the  use  of  COTS/NDI.  The  issues  now 
emerging  which  are  effecting  most  fielded  systems  are  described  piece  meal  in  this  large 
volume  of  information  and  an  attempt  will  be  made  to  summarize,  in  the  discussion 
below,  some  of  the  issues  and  their  associated  root  causes. 

a)  Market  Driven  Forces  Versus  DoDTtimelines 

The  primary  emphasis  behind  the  push  for  the  COTS/NDI  initiative  was 
the  speed  at  which  the  market  forces  drove  the  latest  technology.  In  fact  the  explosion  of 
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new  capability  is  described  in  a  mathematically  identified  expression  called  Moore’s 
Law.  Moore’s  Law  states  that  the  speeds  of  computing  power  will  double  every  eighteen 
months.  It  is  this  new  capability,  which  causes  the  market  place  to  move  forward  at  such 
a  furious  pace,  such  that  it  causes  the  commercial  product  lines  to  cannibalize  older  less 
capable  product  lines,  even  if  they  are  within  the  same  company.  The  results  of  these 
forces  provide  new  product  generations  to  be  developed  and  released  every  18  months. 
In  contrast,  the  development  of  military  systems  traditionally  takes  10-15  years  and  these 
systems  are  then  deployed  and  require  support  for  as  much  as  30  years  or  more.  Many  of 
the  systems  once  deployed  are  fielded  with  out-dated  technologies  that  are  very 
expensive  to  support.  The  COTS/NDI  initiative  provided  a  potential  path  to  infuse  new 
technology  into  the  military  systems  and  at  the  same  time  avoid  the  developmental  costs 
associated  with  grooming  the  new  technology.  As  a  primary  goal  the  initiative  was 
envisioned  to  reduce  the  cost  of  development  while  increasing  the  speed  of  technology 
infusion  into  the  military  systems.  However,  increasing  the  speed  of  deployment  of  the 
newer  technology  into  our  military  systems  acts  as  a  two  edged  sword.  On  the  one  hand, 
the  latest  technology  may  yield  new  capability  at  a  lower  development  cost  and  allow 
continual  upgrades  to  our  military  systems.  On  the  other  hand,  the  rate  of  change 
required  to  keep  pace  with  these  commercial  markets  (i.e.,  every  18  months)  is 
incompatible  with  existing  support  and  product  development  systems  currently  in  place. 
Several  DoD  support  systems  are  purposely  constructed  to  take  a  conservative,  thoughtful 
approach  to  implementing  change  and  provide  obstacles  to  the  time  elements  necessary  to 
keep  pace  with  the  commercial  environment.  What  is  most  important  with  regard  to 
these  conservative  approaches  is  the  disconnect  between  the  life  cycle  of  the  COTS/NDI 
products  (approximately  1.5  -  5  years)  and  the  typical  reaction  time  for  fielded 
equipment  to  be  upgraded  which  is  usually  no  less  than  2-3  years  in  planning  and 
additionally  5-7  years  for  implementation.  This  disconnect  is  further  exacerbated  when 
the  fielded  equipment  is  expected  to  perform  over  an  extended  life  cycle  possibly  greater 
than  15  years.  The  specific  systems  which  have  been  set  up  to  provide  methodical,  time 
phased  controls  on  the  change  process  and  which  impact  the  implementation  of  the 
COTS/NDI  initiative  are  summarized  as  follows: 


PPBS 


Planning,  Programming,  and  Budgeting  System  (PPBS)  -  This  system  is 
intentionally  conceived  to  provide  fiscal  and  planning  oversight.  Consisting  of  a  five  step 
process:  Planning,  Programming,  Budgeting,  Enactment,  and  Execution;  this  process 
takes  2  years  prior  to  the  release  of  funds.  Although  the  system  may  be  short  circuited  by 
reprogramming  of  current  funds,  the  process  is  not  user  friendly  and  may  take  an  act  of 
congress  (to  be  taken  in  the  literal  sense)  to  receive  authority  to  proceed.  Experience  has 
shown  that  following  the  PPBS  process  or  reprogramming  funds  to  meet  obsolescence 
issues  due  to  COTS/NDI  products  is  a  tough  sell,  especially  since  the  new  “wiz-bang” 
system  although  functional  is  not  supportable  or  worse  yet,  obsolete  before  the  design 
engineering  is  complete.  Important  to  note  is  that  once  a  COTS  manufacturer  has  gone  to 
the  next  generation  of  product,  the  previous  product  shall  only  be  supported  for  a  limited 
period  of  time,  usually  1  -2  years.  When  the  support  period  has  passed  the  manufacturer 
abandons  the  earlier  products  -  this  means  no  design  information  is  available,  parts  and 
repair  methods  are  no  longer  available,  and  the  testing  programs  and  test  sets  are  not 
retained.  Therefore  fielded  hardware  cannot  be  supported. 

Repair  &  Support 

DoD  traditionally  developed  project  management  planning  for  programs 
that  have  been  based  on  long  term  deployment  of  fielded  systems  were  supported  by 
various  levels  of  depot  maintenance  activities  and  a  slow  to  respond  material  support 
system.  These  program  plans  have  not  taken  into  account  the  fluid  nature  of  the  COTS 
environment;  therefore  the  program  gets  “blind-sided”  by  unforeseen  changes  that  need 
immediate  attention  to  protect  the  supportability  of  fielded  hardware.  When  dealing  with 
systems  maintenance  the  usual  system  of  depots  is  inappropriate  because  the  government 
never  paid  for  the  design  or  intellectual  property  rights  and  therefore  does  not  know 
enough  about  the  design  or  configuration  to  test  or  repair  the  COTS/NDI  products.  The 
second  major  issue  is  the  lack  of  insight  into  the  product  development  path  taken  by  the 
commercial  manufacturer.  These  manufacturers  will  react  to  their  primary  customers  in 
industry  and  respond  accordingly  to  the  market  forces  regardless  of  what  plans  have  been 
made  by  the  small  “niche”  market  (<  .4%  of  the  business  base)  of  DoD.  In  the  area  of 
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maintainability/supportability  DoD  is  at  the  mercy  of  the  COTS  manufacturer.  However, 
the  procurement  of  spares  for  system  support  is  dependant  on  a  limited  time  availability 
of  products  soon  to  become  obsolete  and  require  intense  focus  by  our  material  support 
systems,  this  will  require  some  level  of  pain  to  meet  required  deadlines. 

Field  Change  Implementation 

Controlling  changes  to  a  baseline,  in  the  design  cycle  or  for  fielded 
hardware,  is  a  convoluted,  time-consuming  process.  In  the  case  of  a  system  currently  in 
the  design  process  it  will  require  multiple  design  reviews,  which  could  lead  to  further 
perturbation  by  involving  oversight  activities  as  identified  in  DoD  5000. 2-R.  In  the  case 
of  fielded  systems  an  ORDALT  (Operational  Requirements  Document  Alteration)  needs 
to  be  prepared,  tested,  materials  purchased,  kits  assembled,  Fleet  assets  scheduled,  visits 
requested  then  made,  kits  installed,  tested,  and  finally  integrated  with  the  particular 
requirements  of  the  specific  hull  involved.  Typically  an  ORDALT  for  a  system  will 
require  at  a  minimum  5-7  years  to  implement  on  combat  weapon  systems.  If  the  change 
to  the  COTS  product  is  provided  as  a  “no  impact”  or  “Drop-in”  replacement  (i.e.,  no 
change  to  form  fit  or  function)  the  process  followed  is  that  which  is  required  for  a  type  2 
Engineering  Change  Proposal  (ECP).  This  process  truncates  the  test  and  evaluation 
process  to  a  mere  30-step  process,  which  based  on  experience,  may  take  6-12  months  to 
complete. 

b)  Interoperability  and  Configuration  Control 

Interoperability  through  open  systems  architecture  is  still  a  dream,  which 
has  not  been  realized  in  our  fielded  systems.  Our  current  fielded  systems  are  closely 
coupled  and  rely  in  a  great  extent  on  the  hardware  characteristics  of  specific  products. 
These  characteristics  must  remain  stable  for  the  software  intensive  combat  weapon 
systems  to  function  and  meet  their  certification  requirements.  One  of  the  major  flaws  of 
the  COTS/NDI  initiative  is  the  lack  of  control  over  the  configuration  of  COTS  products. 
The  government  is  purchasing  an  off-the-shelf  product  but  not  the  design,  design 
disclosure  nor  the  assurance  of  a  configuration  to  be  controlled  to  some  pre-planned 
baseline.  The  manufacturer  has  no  requirement  to  inform  the  government  of  any  changes 
to  the  internal  hardware  or  software  (firmware)  characteristics  of  their  COTS  products. 
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The  manufacturer  specification  sheets  only  provide  inputs  and  outputs  in  rather  vague 
tenns,  which  will  satisfy  the  needs  of  their  primary  customers  in  industry.  Although  this 
point  seems  to  be  a  minor  issue  to  the  commercial  customers,  with  military  combat 
weapon  systems  built  on  closely  coupled  software  the  result  can,  and  many  times  is, 
catastrophic.  A  simple  change  of  an  internal  chip  using  different  firmware  has  required 
thousands  of  hours  of  software  engineering  to  get  a  combat  weapon  system  to  function 
then  many  more  test  hours  to  re-certify  the  system  for  use.  In  defining  the  COTS/NDI 
policy  an  assumption  was  made  that  control  over  the  configuration  was  either 
unnecessary  or  that  our  systems  were  robust  enough  to  handle  the  perturbations  of 
potential  change,  neither  is  true.  Our  currently  fielded  systems  are  very  sensitive  to  small 
changes  and  the  stability  of  the  hardware  is  paramount  in  the  continued  supportability  of 
those  systems. 

D.  BENEFITS  OF  THE  SSB  SYSTEM 
1.  Objectives  and  Goals 

a)  Expectations 

Understanding  the  needs  of  the  customers  we  must  now  derive  specific 
goals  to  meet  those  needs.  These  goals  we  must  be  related  to  our  national  defense 
strategy  and  acquisition  policies.  To  align  the  customer  needs  with  appropriate  goals  it  is 
crucial  to  understand  the  necessity  for  effective  collaboration  between  the  warfighter,  the 
program  offices,  and  private  industry  to  successfully  meet  the  system  requirements.  To 
this  end,  we  expect  the  architectural  form  of  such  a  process  will  exhibit  the  characteristics 
of  a  collaborative  system,  which  necessitates  voluntary  participation.  Figure  1  -  The 
COTS  Collaborative  Environment  -  depicts  a  conceptual  illustration  of  such  a 
collaborative  system  within  the  Navy  for  the  Sunset  Supply  Base.  This  voluntary 
participation  is  needed  for  the  assemblage  and  maintenance  of  such  a  system  and  is 
crucial  to  its  success.  Success  will  be  measured  continuously  for  those  properties  that 
emerge  against  how  well  they  fulfill  the  purpose  and  how  well  they  are  managed  to 
accomplish  their  specified  tasks.  Through  abstraction  we  can  visualize  a  system  that  has 
very  distinct  elements  that  work  together  for  mutual  gain  and  to  satisfy  a  common  need. 
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Therefore,  we  can  expect  that  such  a  system  should  evolve  from  existing  support 
structures,  processes,  and  methods  currently  used  in  support  of  the  Navy’s  systems. 


Assessment/Reporting/ 
Facilitating  Activity 


Figure  1:  The  COTS  Collaborative  Environment 


b)  Sunset  Supply  Base  Objectives 


The  objectives  of  the  SSB  process  provide  the  rational  for  deciding  to 
implement  the  SSB  infrastructure.  By  formally  stating  the  overall  objectives  of  this 
subject,  we  essentially  establish  a  basis  by  which  the  analysis  can  assign  values  to 
specific  benefits  and  ultimately  guide  this  effort  into  making  a  reasonable  conclusion 
statement  and  provide  realistic  recommendations.  These  objectives  are  categorized  and 
discussed  below. 

Financial  and  Business  Performance 


The  overall  objective  mandated  by  the  current  DoD  Systems  Acquisition 

Process  (DoD  5000)  is  to  improve  performance,  including  quality,  at  lower  costs.  This 

process  focuses  on  delivering  advanced  or  at  least  current  technology  to  the  warfighter 

faster.  PMOs  are  challenged  to  offer  rapid  acquisition  of  reliable  and  supportable 

technology  while  also  reducing  Total  Ownership  Costs  (TOC)  and  improved 
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affordability.  In  meeting  this  challenge,  we  see  a  proliferation  of  interoperable  systems 
using  COTS  products.  Quite  often  the  use  of  similar  COTS  across  weapon  systems  that 
are  separate  and  distinct  which  have  no  physical  or  logical  dependence  on  each  other 
share  the  same  COTS  items.  The  use  of  COTS  in  itself  brings  a  certain  risk  of  being  able 
to  support  them  long-term  due  to  Diminishing  Manufacturers  Sources  and  Material 
Shortages  (DMSMS)  and  obsolescence.  The  fact  that  many  different  programs  or 
weapon  systems  are  using  the  same  COTS  products,  only  increases  the  risk  and  threat  to 
system  sustainability  across  these  programs.  Therefore,  the  SSB  process  attacks  these 
two  areas,  risk  and  costs,  by  providing  a  potential  architectural  solution  that  specifically 
addresses  the  issue  of  obsolescence  and  DMSMS  problems,  thereby  reducing  both  risk 
and  costs  to  the  program.  In  answering  the  mail  on  this,  the  SSB  process  strives  to 
compress  the  provisioning  timeframes,  by  partnering  with  private  industry  and  providing 
them  with  incentives  (as  previously  mentioned)  to  assume  some  of  the  risk  (i.e., 
immediate  supportability  and  warranty)  and  costs  (i.e.,  stockage,  storage  and  issue  of 
COTS  spares  and  repair  parts).  Doing  so,  will  have  positive  impacts  in  terms  of 
supportability,  program  planning,  program  risk  and  TOC. 

Strategic  Position  and  Ownership 

Partnering  with  the  private  sector  to  take  advantage  of  commercial 
technology  advances  as  well  as  the  support  and  maintenance  of  COTS  products  are 
firmly  established  mechanisms  used  by  the  DoD/Navy.  DoD  detennined  a  potential  cost 
savings  would  be  possible  by  pooling  the  expertise  and  capabilities  found  in  private 
industry.  Partnering  takes  on  many  forms  (i.e.  teaming,  procurement/sales,  work-share 
arrangements);  but  the  important  point  here  is  that  they  exist  and  are  being  utilized  more 
and  more  by  the  PMOs.[5)  OSD]  Furthermore,  the  Program  Manager  as  part  of  the 
acquisition  strategy  must  establish  a  support  strategy.  In  fact,  this  plan  must  “address 
life-cycle  sustainment  and  continuous  improvement  of  product  affordability,  and 
supportability,  while  sustaining  readiness. ”[6)  OSD],  To  this  end,  the  Program  Manager 
has  at  their  disposal  a  set  of  tools  to  help  in  the  decision-making  process  for  detennining 
the  most  cost  effective  alternative  for  supporting  the  system.  The  SSB  architecture  is 
challenged  to  position  itself  within  this  toolset  as  a  viable  alternative.  A  strategy  for 
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positioning  the  SSB  architecture  within  the  supportability  analysis  repertoire  would 
include  establishment  or  improvement  of  strategic  alliances.  The  SSB  architecture  has 
already  been  implemented  on  three  Navy  programs  (SSDS  MKI,  SSDS  MKII  and 
AN/AQS-20/X  Sonar  Mine  Detection  Set).  The  relationships  developed  between  the 
participating  commercial  entities  and  the  Navy  agencies  should  lobby  the  DoD  Program 
Executive  Offices  (PEO)  with  sufficient  detail  as  to  the  benefits  of  implementing  the  SSB 
architecture  on  the  respective  programs.  Since  the  SSB  architecture  was  built  on  existing 
expertise  and  functions  within  the  Navy,  the  SSB  process  is  in  fact  owned  and  therefore 
managed  by  the  DoD/Navy.  Additionally,  the  long-term  relationships  that  will  be 
realized  through  the  SSB  environment  should  further  emphasis  and  influence  the  policy¬ 
making  office  within  the  DoD  as  to  the  potential  gains,  not  only  in  the  performance  of 
supportability  and  sustainability  functions,  but  in  maintaining  key  technologies  as  well. 

Operations  and  Functions 

The  objective  here  is  simple  -  to  improve  program  supportability  by 
extending  COTS  reparability  for  5  years  and  beyond.  Why  5  years?  Typically,  the 
development  of  military  systems  has  been  10  to  15  years,  and  the  DoD/Navy  have 
experienced  approximately  5  to  7  year  efforts  for  technology  refresh  or  insertion.  The 
reason  for  this  is  primarily  due  to  the  inherent  nature  of  DoD  to  take  a  purposely 
conservative  and  thoughtful  approach  to  implementing  change.  DoD  has  constructed 
very  well-defined  controls  for  managing  the  acquisition  process,  which  have  in  effect 
created  obstacles  for  keeping  pace  with  commercial  product  development.  This 
conservative  approach  has  resulted  in  disconnect  between  the  life  cycle  of  COTS 
products  and  the  typical  reaction  time  of  the  DoD/Navy  to  field  new  equipment.  The  life 
cycle  for  COTS  products  are  approximately  18  months  to  as  much  as  5  years  (although 
rare),  whereas  the  DoD  typically  takes  2  to  3  years  in  planning  and  an  additional  5  to  7 
years  for  implementation.  The  problem  of  supporting  these  weapon  systems  is  further 
compounded  when  these  weapon  systems  are  expected  to  perform  over  an  extended  life 
cycle  -  possibly  greater  than  15  years.  Given  this  situation,  the  SSB  process  has 
identified  as  an  objective  to  support  the  product  development  cycle  and  ultimately  the 
system  life  cycle.  For  weapon  systems  that  have  deployed  COTS,  the  SSB  architecture 
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offers  an  opportunity  for  supporting  existing  technologies.  Success  in  these  areas  will 
fulfill  the  SSB  architecture’s  commitment  to  improving  operations  and  functions  for  the 
PMO  since  they  are  the  entity  who  are  responsible  to  manage  the  program  over  its 
lifetime. 

Product  and  Services 

In  terms  of  product  and  service,  the  SSB  architecture  offers  a  truly  unique 
and  effective  process  for  improving  customer  satisfaction.  The  customer  in  this  case  is 
the  warfighter  who  use  and  maintain  the  system.  The  PMO  must  ensure  that  they  deliver 
key  enabling  technologies  that  must  also  be  supportable  for  fixed  periods  of  time.  The 
SSB  architecture  offers  an  additional  alternative  for  the  PMO  to  consider  as  part  of  their 
support  strategy.  Furthermore,  the  SSB  process  allows  the  program  manager  to  match 
the  COTS  update  cycles  with  the  program’s  technical  roadmap  or  refresh  effort.  The 
product  is  essentially  a  set  of  well-defined  tools  that  provide  obsolescence  indicators  and 
reports,  as  well  as  the  ability  to  mitigate  maintenance  and  supportability  issues  at  the 
assembly  level.  Establishing  and  managing  this  infonnation,  the  PMO  becomes 
empowered  with  the  knowledge  necessary  to  deliver  an  improved  customer  service.  In 
the  long  run  the  system  integrity  is  maintained,  which  has  several  implications  in  terms  of 
integrated  logistical  support  (i.e.,  training,  manuals,  configuration  control.) 

Image 

This  is  an  unusual  area  since  we  are  not  talking  about  the  image  of  a 
specific  entity  like  an  agency  or  company.  The  objective  here  is  to  promote  the  idea  of 
the  SSB  architecture  as  a  viable,  effective  and  valuable  alternative  based  on  costs  and 
benefits.  At  first  glance,  it  may  appear  to  some  that  the  SSB  process  is  trying  to  hold 
onto  older  technology.  Old,  meaning  technology  associated  with  COTS  products  that 
have  been  discontinued.  The  fact  of  the  matter  is  that  the  DoD/Navy  has  not  been  able  to 
keep  up  with  commercial  product  update  cycles.  In  a  perfect  world,  it  would  be  great  to 
be  able  to  transfer  commercial  state-of-the-art  technology  to  the  warfighter  the  moment  it 
was  deemed  ready  or  at  least  when  it  emerges  in  the  market.  But  the  acquisition  process 
institutionalized  by  the  DoD  offers  too  many  obstacles  to  achieve  this.  Although 
Acquisition  Reform  has  yielded  great  gains  in  streamlining  the  acquisition  process,  it  is 
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still  purposely  conservative,  deliberate  and  methodical,  which  translates  to  slow  when 
compared  to  the  current  commercial  development  cycles.  Although  DoD  pressures  the 
PMOs  toward  COTS  products  for  the  reasons  discussed  earlier,  it  does  not  adequately 
define  all  aspects  of  supporting  them.  The  military  acquisition  community  is  pushed  by 
DoD  5000  to  use  COTS  products  as  the  preferred  alternative  for  use  in  its  weapon 
systems,  whereby  the  obsolescence  issues  are  slowly  getting  worse.  So  even  though  the 
use  of  COTS  products  is  growing,  the  PMOs  continually  struggle  with  DMSMS  issues, 
which  is  why  they  routinely  fund  and  support  DMSMS  activities  to  meet  the  Navy’s  ever 
increasing  need.  The  SSB  system  is  designed  to  specifically  address  these  risks,  but  more 
importantly,  it  is  expected  to  work  with  existing  support  systems  as  an  interfacing  method 
to  optimize  solutions  in  managing  the  obsolescence  risk  on  COTS  products. 
Furthermore,  not  only  does  the  SSB  system  offer  significant  supportability  and  cost 
benefits  to  the  Program  Offices,  it  also  strives  to  be  recognized  as  a  contributor  in 
Navy/Industry  cooperation,  a  major  initiative  underway  particularly  in  the  Navy.  A 
major  objective  of  this  effort  is  to  establish  the  SSB  system  as  a  unique  standard  practice 
while  projecting  its  image  as  an  enabler  of  currently  used  support  systems,  that  are 
employed  during  the  decision-making  processes  regarding  supportability  of  COTS 
products.  The  results  derived  from  implementation  on  three  Navy  programs 
demonstrates  how  the  SSB  system  is  a  collaborative  system  in  which  the  participants 
voluntarily  use  the  system  and  in  return  receive  value  added  products  and  outputs. 

c)  SSB  Specific  Goals 

The  systems  architecture  shall  have  the  following  goals: 

To  be  able  to  identify,  quantify,  and  mitigate  supportability  risk  to 
programs. 

This  process  must  be  affordable  and  be  able  to  successfully  assess  the  cost 
savings  attributed  to  the  process.  The  infonnation  derived  from  identification  and 
mitigation  of  supportability  risk  shall  be  quantifiable  and  readily  accessible  by 
participants. 
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Extend  the  life  cycle  and  supportability  of  COTS. 

Supportability  of  fielded  hardware  shall  be  defined  by  the  warfighter.  The 

process  shall  take  this  into  account  as  it  defines  the  metrics  for  assuring  late-life  cycle 

supply  source.  To  be  successful  the  DoD  shall  continue  to  leverage  commercial 

developments  with  appropriate  economies  of  scale  in  order  to  reach  expected  military 

performance  goals  and  still  offset  the  problem  of  diminishing  material. 

Provide  infrastructure  to  support  existing  platform/combat  systems  in 
support  of  the  Program  Office. 

This  goal  is  to  provide  an  infrastructure  earlier  in  the  development  process 
to  demonstrate  and  prove  COTS  components  and  to  support  existing  weapon  systems. 
This  will  provide  significant  reduction  in  program  risk  as  related  to  COTS  and  life  cycle 
management. 

Achieve  significant  and  quantifiable  cost  savings  over  the  product  life  cycle. 

Cost  structures  shall  be  tracked  and  continually  assessed  over  the  entire 
product  life  cycle.  This  will  significantly  impact  the  effectiveness  of  informed  decision¬ 
making  that  is  needed  for  success.  The  up  front  cost  assessments  will  contribute  to  the 
life  cycle  cost  savings,  due  to  NO  lifetime  buys  at  the  assembly  level.  The  assemblies 
would  be  procured,  as  the  customer  requires  them. 

A  reliable,  affordable,  repeatable,  and  expandable  process  that  meets  the 
customer’s  performance  expectations  (e.g.,  accessible,  transportable, 
maintainable,  predictable). 

The  process  shall  have  definable  and  repeatable  characteristics  in  order  to 

provide  a  comprehensive  and  flexible  solution  to  supporting  fielded  hardware.  It  shall 

provide  an  independent  utility  (an  alternative  option  for  DMSMS/Obsolescence 

Management)  for  programs  when  implementing  COTS  products  and  whose  solutions  will 

have  minimal  or  no  impact  on  system  operational  performance. 

Institutionalize  methods  for  proactive  management  of  COTS  including 
DMSMS  issues. 

The  institutionalization  of  these  methods  will  require  the  development  of 

non-standard  Integrated  Logistics  Support  (ILS)  and  contract  strategies  and 

implementation  methodologies  that  will  access  the  commercial  support  base.  In  doing 
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this,  the  process  must  be  sensitive  to  proprietary  design  rights  and  provide  a  forum  for 
appropriate  negotiations.  The  methods  employed  shall  improve  product  supportability 
problem  detection  and  provide  sufficient  time  for  appropriate  decision-making  processes 
to  implement  analysis  for  alternatives  and  solutions.  Overall  it  shall  provide  aid  to  the 
decision-maker  by  providing  technology  assessment  and  management  guidance  at 
various  levels  -  piece  parts,  lowest  replaceable  units,  units,  subsystems  and  multiple 
platforms. 

A  system  that  leverages  Navy  and  commercial  supportability  assets  and 
provides  a  networked  solution. 

The  process  must  take  advantage  of  inherently  governmental  functions  for 

DMSMS  Management  at  the  various  field  activities  and  coordinate  with  the  commercial 

supportability  assets.  This  coordination  must  be  embraced  through  a  thoroughly  meshed 

and  maintainable  communication  network. 

Leverage  across  government  programs  with  extended  applicability  through 
contract  strategies,  methodologies,  and  incentives  to  entice  commercial 
industry  participation. 

The  process  must  be  transportable  in  tenns  of  its  applicability  to  various 
DoD  entities  and  their  contract  strategies.  Aggressive  integration  of  common 
components  across  DoD  entities  should  lead  to  flexible  integrated  logistical  support  of 
COTS  products  and  should  provide  incentive  for  the  commercial  industry  to  develop 
long-term  relationships. 

Forecast  budget  requirements  in  support  of  the  programs/war 
fighter/consumer. 

The  process  shall  provide  predictive  infonnation  for  the  decision-making 

components  of  the  DoD  program  offices.  In  forecasting  budget  requirements  in  support 

of  programs/warfighter/customer  the  outputs  from  trade-offs  and  assessments  must 

achieve  a  high  level  of  confidence  with  the  program  office. 

Improve  schedule  flexibility  and  support  options  of  system  upgrades  or  new 
development  initiatives. 

The  process  should  incorporate  improved  schedule  flexibility  and  support 
options  that  can  be  tailored  for  the  warfighter  and  the  support  activities  needs.  One  of  the 
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main  objectives  shall  be  the  compression  of  provisioning  timeframes.  To  this  end, 
increased  responsibility  on  the  contractor's  part  is  assumed  in  tenns  of  stockage,  storage 
and  issue  of  COTS  spares  and  repair  parts.  The  benefits  that  we  will  strive  to  achieve 
shall  include  immediate  supportability,  elimination  of  government  levels  of  inventory 
stock,  employ  large  commercial  distribution  systems,  no  source  inspection,  commercial 
packaging,  fast  and  direct  delivery  to  the  warfighter,  and  warranty  of  components. 

E.  SCOPE  AND  METHODOLOGY 
1.  Scope 

The  scope  of  this  thesis  is  broken  down  into  essentially  four  deliverables: 

a)  System  Architecture 

The  overall  purpose  is  to  provide  dependable,  cost  effective  supportability 
insurance  for  COTS  based  weapon  systems.  The  result  will  provide  a  solution  to  COTS 
obsolescence  issues,  material  shortages  issues,  and  extend  the  supportability  of  COTS 
components.  The  architecture  should  address  COTS  technology  obsolescence 

management  through  product  and  technology  obsolescence  forecasting  methodologies 
and  provide  a  new  process  for  managing  changes  with  COTS  based  systems.  The  final 
architecture  should  respond  to  the  voice  of  the  customer,  who  is  demanding  credible 
combat  power  through  design  and  supportability,  by  putting  speed  and  agility  into  the 
process,  and  ultimately  provide  some  value  as  perceived  by  the  customers 

b)  System  Engineering  Development  and  Implementation  (SEDI) 

Plan 

The  purpose  of  this  plan  is  to  put  into  perspective  the  processes,  methods 

and  tool  needed  to  implement  the  Sunset  Supply  Base  (SSB)  system.  This  document  is 

presented  as  a  “stand-alone”  prescriptive  set  of  actions,  which  can  be  taken  in  the 

establishment  of  an  SSB  system.  However,  this  document  does  not  portend  that  it  is  the 

only  process  or  method  to  establish  such  a  system  but  instead  is  the  method  the  authors 

had  chosen  to  implement  the  SSB  system.  The  document  is  constructed  in  three  major 

sections,  which  follow  a  brief  introduction  to  the  SSB  system  concept.  The  primary 

issues  grappled  with  in  the  SEDI  plan  are  those  faced  during  implementation  and 

encountered  primarily  when  bringing  the  idea  into  reality.  The  first  section  of  the  plan 
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address  introduction  to  the  program  and  the  infrastructure  needed  to  support  the  effort, 
such  areas  as:  teaming  structure,  computer  resources,  communication  methods,  interface 
with  the  Programs,  data  structure  requirements,  management  participation,  etc.  The 
second  section  of  the  plan  covers  the  implementation  of  the  SSB  system  and,  in  turn, 
presents  many  challenges  to  overcome  in  realizing  the  SSB  system.  Examples  of  some  of 
these  challenges  include:  identification  of  the  COTS  Original  Equipment  Manufacturers 
(OEM),  interface  methods  with  the  OEMs,  interface  with  the  Program,  understanding  the 
Programs  needs  and  requirements,  building  relationships  between  the  OEMs  and  the 
Navy,  identifying  suitable  partnerships  between  the  OEMs  and  small  build-to-print 
suppliers  where  applicable.  The  final  section  of  the  plan  identifies  methods  and  metrics 
to  measure  the  impact  of  implementing  a  SSB  system,  thereby  providing  adequate 
indicators  for  the  programs  to  assess  the  effectiveness  and  value  proposition  in  using  the 
system. 

c)  Business  Case  Analysis  (BCA) 

The  Business  Case  Analysis  focuses  on  the  Sunset  Supply  Base  system  for 
supporting  Navy  hardware  that  incorporates  the  use  of  Commercial  Off  The  Shelf 
(COTS)  products.  It  is  offered  as  a  tool  that  supports  planning  and  decision-making  for 
SSB  implementation.  The  Business  Case  Analysis  (BCA)  was  performed  for  the  Ship 
Self-Defense  System  (SSDS)  MKI  but  can  be  applied  to  any  acquisition  program.  The 
BCA  addresses  the  financial  and  non-financial  consequences  of  implementing  the  SSB 
on  the  SSDS  MKI  program.  Not  only  does  it  show  the  funding  profiles  for  various 
scenarios  of  support  it  also  includes  the  methods  and  rationale  that  were  used  for 
quantifying  benefits  and  results.  The  baseline  constraints  of  this  case  is  a  time  period  of 
ten-years  which  gives  us  a  framework  for  providing  decision-makers  key  information  for 
developing  program  strategies  and  execution  tactics  for  reducing  cost,  improving 
supportability  requirements  and  reducing  risk. 

d)  Marketing  Plan 

This  Marketing  Plan  is  one  of  the  four  foundational  documents  created  to 

establish  the  SSB  system  as  a  Commercial  off  the  Shelf  (COTS)  supportability  alternative 

for  Navy  fielded  systems  containing  COTS  products.  The  plan  analyzes  the 
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environments  (external,  internal,  customer)  in  which  the  marketing  functions  will  be 
operating.  The  SSB  system  is  evaluated  for  its  attributes,  both  positives  and  negatives 
through  a  “SWOT”  (Strengths,  Weaknesses,  Opportunities,  Threats)  analysis.  Each  of 
these  characteristics  is  then  matched  to  a  marketing  strategy  to  improve  the  system’s 
marketability.  Two  goals  are  set:  A)  capture  20%  of  market  share  (72  Navy  programs  or 
80  man-yr  per  year  effort),  B)  Establish  an  image  for  the  SSB  system  as  the  alternative  of 
choice  for  COTS  supportability  that  enables  cost  effective  technology  insertion  in  fielded 
Navy  systems.  Based  on  a  defined  “Target  Market”,  a  “Marketing  Mix”  is  defined  that 
identifies  a  series  of  marketing  action  to  take  to  achieve  a  competitive  advantage  for  the 
SSB  system  in  maximizing  market  penetration.  This  Marketing  Plan  is  an  integral  part  of 
overall  System  Engineering  approach  used  to  develop  the  SSB  system  whereby  the 
implementation  of  the  Marketing  Plan  is  contained  within  the  system  implementation 
process. 

2.  Methodology 

The  methodology  is  focused  on  the  previously  described  four  deliverables  in  and 
effort  to  exhaustively  address  the  main  problem  described  within  this  document  of 
supporting  COTS  product  usage  within  military  weapon  and  support  systems.  In  doing 
so,  the  method  takes  a  four-step  approach  that  is  aligned  with  each  deliverable. 

STEP  1.  Create  an  architecture  that  can  affordably  and  effectively  mitigate 

program  supportability  risk. 

The  methodology  used  during  the  development  of  the  System  Architecture  for  the 
SSB  system  required  review  and  evaluation  of  various  attributes  which  contribute  to  the 
supportability  or  lack  of  supportability  of  the  COTS  products  in  Navy  systems.  The  first 
area  reviewed  dealt  with  defining  the  current  issues  with  the  COTS  products  as  perceived 
by  the  Fleet,  the  PMOs,  the  program  support  teams,  the  OEM  suppliers,  the  Fleet  support 
activities,  and  internal  Navy  support  infrastructures.  To  accomplish  this  task  an 
exhaustive  literature  search  was  done  and  combined  with  the  results  from  interviews  with 
each  group  affected.  These  efforts  identified  several  problems  and  systemic  issues  that 
needed  to  be  addressed  in  the  architecture.  The  next  area,  which  needed  to  be  evaluated 
was  the  structure  and  dynamics  of  the  current  support  systems,  identifying  how  these 
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system  met  the  unique  characteristics  presented  through  the  use  of  COTS  products.  With 
this  evaluation  in  hand,  a  gap  analysis  was  done  to  pinpoint  shortcomings  in  current 
support  strategies  and  practices.  An  environmental  analysis  both  pre-and-post 
Acquisition  Reform  (AR)  was  accomplished  to  identify  potential  causes  and  candidate 
resolutions.  The  pre  AR  environment  was  characterized  by  a  rules-based,  hierarchical, 
requirements  rich  environment  defined  through  the  use  of  military  specifications,  this 
yielded  a  risk  adverse  posture.  The  post  AR  environment  was  characterized  by  a 
performance  based  environment  which  resulted  in  a  requirements  poor  environment  that 
necessitated  a  risk  management  posture.  The  pre-and-post  AR  environments  provided 
the  backdrop  and  context  in  which  to  interpret  the  feedback  we  received  from  the 
different  entities  interviewed.  The  architectural  form  chosen  was  a  collaborative 
architecture  and  was  formulated  through  the  evaluations  and  analysis  identified  above 
and  is  documented  in  Appendix  A  -  Systems  Architecture  for  the  SSB  system  . 
Development  of  the  architecture  followed  the  sequential  steps  listed  below,  which  defines 
major  attributes/characteristics  of  the  architecture. 

•  Need 

•  Purpose 

•  Goals  -  Expectations,  Objectives,  &  Specific  Goals 

•  Collaborative  Concept 

•  Function  &  Form  -  Overarching  System,  SSB  Standalone  System,  Interface 
Management 

•  Timing 

•  User  Environment 

STEP  2.  Implement  the  architecture. 

The  second  step  is  the  actual  setup  and  execution  of  the  SSB  architecture. 
Implementation  occurred  on  the  SSDS  MKI  &  MKII  Systems  and  the  AN/AQS-20/X 
Sonar  Mine  Detection  Set.  Implementation  was  accomplished  with  specific  expectations. 
First,  in  order  to  effectively  assess  the  overall  value  and  feasibility,  measurable  goals 
which  was  established  under  the  architectural  design  of  the  SSB  system  would  be  used  as 
evaluation  criteria.  Furthermore,  the  implementation  would  provide  crucial  financial  data 

to  be  analyzed  as  quantifiable  measures.  The  information  derived  from  this  step  is 
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categorized  into  financial  and  non-financial.  The  financial  information  would  support  the 
Business  Case  Analysis  (BCA)  whereas  the  non-financial  would  provide  lessons  learned. 
The  experiences  of  implementation  are  to  be  recorded  and  presented  as  guidance  within  a 
formalized  Systems  Engineering  Development  and  Implementation  Plan.  Actual 
implementation  would  also  yield  both  benefits  and  shortcomings  that  help  significantly  to 
improve  the  system  during  the  evolutionary  process,  the  expected  development  path  for 
our  collaborative  system.  In  short,  this  step  provides  two  key  elements  that  contribute  to 
this  effort: 

8)  Lessons  learned  and  valued  experienced  that  supports  the  establishment  of  a 
Systems  Engineering  Development  and  Implementation  Plan,  which  is  offered 
as  guidance  for  future  SSB  architecture  implementations. 

9)  Specific,  quantifiable  data  collected  for  evaluation  and  analysis  conducted 
under  the  Business  Case  Analysis. 

STEP  3:  Conduct  a  Business  Case  Analysis. 

In  this  step  we  conduct  a  business  case  analysis  of  the  actual  SSB  implementation 
on  the  Ship  Self-Defense  System  MKI.  This  system  was  chosen  as  a  case  study  because 
it  provided  the  most  data  and  experience  in  terms  of  the  SSB  process.  The  outcome  of 
this  step  is  a  document  that  essentially: 

1)  Organizes  data  collected  in  the  previous  step. 

2)  Converts  the  data  into  useable  and  pertinent  information. 

3)  Analyzes  the  results. 

4)  Derives  knowledge  from  the  results. 

5)  Makes  appropriate  recommendations. 

In  following  this  general  5 -step  process,  the  final  document  serves  as  a  tool  that 
supports  the  planning  and  decision-making  with  respect  to  implementing  the  Sunset 
Supply  Base  system.  Of  course,  it  could  not  be  expected  that  the  SSB  system  would  be 
the  solution  for  all  Navy  programs  nor  is  it  intended  to  replace  traditional  support 
practices,  but  this  step  intends  to  show  how  the  SSB  architecture’s  true  value  is  realized 
when  its  implementation  is  in  conjunction  with  current  processes.  In  fact,  the  acceptance 
of  the  SSB  system  only  provides  the  program  manager  with  additional  cost  effective 
solution  scenarios  in  terms  of  weapon  system  support,  maintainability  and  operational 
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readiness.  This  document  focuses  on  the  SSB  as  a  viable  solution  alternative  for  the 
Navy  Program  Offices  to  consider  in  their  decision-making  efforts  with  respect  to 
optimizing  return-on-investment  (ROI).  The  phrase  re tum-on- investment  is  not 
necessarily  used  in  the  strict  sense  here,  but  rather  alludes  to  the  challenge  of  reducing 
life-cycle  costs  while  maintaining  adequate  support  levels  and  system  baseline  stability 
over  predefined  periods  of  time.  However,  since  ROI  is  in  effect  a  measure  of  a 
company’s  performance,  it  is  appropriate  in  this  case  since  the  task  of  the  Program 
Offices  is  to  get  the  “most  bang  for  the  buck”,  which  is  in  essence  a  measure  of  their 
performance.  The  analysis  presented  within  the  BCA  considers  several  financial  metrics 
and  how  they  relate  to  the  value  of  this  business  case  in  the  selection  process.  The 
Business  Case  Analysis  (BCA)  will  detail  the  likely  financial  results  and  business 
consequences  of  implementing  the  SSB  system  so  that  the  proposed  benefits  and  risks  are 
succinctly  documented  and  understood. 

The  BCA  looks  at  the  implementation  of  the  SSB  system  on  the  Ship  Self- 
Defense  System  (SSDS)  Mkl.  It  considers  the  consequences  of  implementing  the  SSB 
infrastructure  for  providing  COTS  support  for  the  SSDS  program.  These  consequences 
include  both  tangible  and  intangible  results,  and  are  analyzed  for  confonnance  to  DoD 
policy,  program  requirements  and  overall  cost/benefit.  Furthermore,  it  looks  at  how  well 
the  actual  implementation  relates  to  the  goals  and  objectives  of  the  SSB.  In  short,  the 
business  case  examines  the  likely  costs  and  benefits  that  will  result  in  implementing  the 
SSB  system  for  supporting  the  SSDS  program.  In  considering  SSB  implementation  the 
analysis  reports  on  four  scenarios: 

1)  Traditional  support  practices. 

2)  Full  SSB  implementation  in  which  all  COTS  components  are  support  via 
Sunset  Supply  Base  infrastructure. 

3)  Partial  SSB,  where  only  those  COTS  components  are  supported  in  which  the 
OEM  and/or  Sunset  Supplier  have  agreed  to  enter  into  a  contractual 
relationship. 

4)  Modified  SSB  implementation,  where  the  use  of  the  SSB  system  is  only  used 
where  it  makes  sense.  The  SSDS  COTS  Working  Group,  which  is  responsible 
for  overall  execution  and  management  of  the  SSB  system  for  a  particular 
program,  makes  these  decisions. 
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STEP  4:  Development  of  a  Marketing  Plan 

In  this  step  a  Marketing  Plan  was  established  that  promotes  the  SSB  system  as  a 
Commercial  off  the  Shelf  (COTS)  supportability  alternative  for  Navy  fielded  systems 
containing  COTS  products.  This  document  defines  the  marketing  strategy  and 
boundaries  for  gaining  DoD  recognition  and  acceptance  as  a  “value  added”  support 
solution  alternative.  In  essence,  the  Marketing  Plan  brings  together  the  details  of  the 
previous  steps  and  relates  them  to  the  environment  and  community  to  which  the  SSB 
system  will  exist.  The  environmental  and  community  aspects  are  researched  and 
documented  in  terms  of  the  external  (private)  and  internal  (organic)  environments, 
expected  competition,  policy  and  legal  constraints,  and  forecasts  or  estimates.  The 
Marketing  Plan  then  identifies  and  lists  the  SSB  system’s  strengths,  weaknesses  , 
opportunities  and  threats  -  commonly  referred  to  as  a  SWOT  Analysis.  The  SWOT 
Analysis  is  an  effective  mechanism  for  focusing  available  energy  in  tenns  of  SSB  system 
acceptance  into  areas  or  programs  that  are  believed  to  be  where  the  SSB  system  can  be 
most  effective.  Also,  this  analysis  helps  in  divulging  the  greatest  opportunities  for  future 
SSB  implementations.  In  addition,  this  analysis  helps  to  uncover  and  identifies  potential 
problems,  puts  these  problems  into  perspective,  and  establishes  what  important  tasks 
have  to  be  perfonned  to  overcome  these  problems.  The  Marketing  Plan  is  neither  an 
independent  or  stand  alone  process/method,  instead  it  is  embedded  as  an  integral  part  of 
the  SSB  system  itself  such  that  a  marketing  customer  focus  is  maintained  throughout  all 
aspects  of  the  approach.  Therefore  in  order  to  understand  the  marketing  implementation 
efforts,  knowledge  of  the  SSB  systems  implementation  or  SEDI  plan  is  necessary. 

Each  step  of  the  methodology  is  encapsulated  and  delivered  as  a  stand-alone 
document  (Appendices  A-D)  that  specifically  addresses  the  SSB  system  from  four 
interrelated  perspectives.  The  System  Architecture  defines  the  problem  and  proposes  a 
well  thought  out  holistic  solution  alternative  that  establishes  clearly  define  objectives  and 
goals.  The  Systems  Engineering  Development  and  Implementation  (SEDI)  Plan 
effectively  puts  the  SSB  System  into  practice.  Implementation  and  execution  of  the  SSB 
process  is  then  assessed  with  respect  to  the  established  goals,  objectives  and  expectations 
offered  in  the  System  Architecture  plan.  This  implementation  helps  to  collect  valuable 
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data  to  support  continuous  evolution  of  the  SSB  process  as  well  as  developing  a  BCA  and 
Marketing  Plan.  The  BCA  converts  the  data  into  infonnation  for  analysis  and  reports  on 
the  results  leading  to  knowledge  that  directly  supports  and  enhances  the  decision-making 
process.  Additionally,  the  BCA  offers  recommendations  and/or  feedback  for  SSB  system 
improvement.  Finally,  the  Marketing  Plan  feeds  off  of  the  SSB  implementation  (lessons 
learned  and  overall  experiences)  and  the  BCA  results,  as  well  as  environmental  study, 
and  develops  a  strategy  that  provides  guidance  for  future  SSB  implementation 
opportunities. 
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II.  LITERATURE  REVIEW 


A.  PROBLEM  STATEMENT 

Acquisition  Reform  and  the  policies  that  it  invoked  brought  about  the 
implementation  of  COTS.  Those  policies  required  the  avoidance  of  unique  requirements, 
restrictive  statements  of  need,  and  detailed  specifications.  Together  with  DoD  5000.2 
and  the  Federal  Acquisition  Regulations  (FAR),  DoD  hoped  to  leverage  the  large 
businesses  in  tenns  of  state-of-the-art  technologies  and  quantity  of  manufacturing  in 
order  to  provide  state-of-the-art  technology  at  lower  costs.  COTS  technologies  are  driven 
by  the  market  forces  of  that  industry,  and  the  COTS  manufacturers  are  driven  by  their 
customer  base  of  which  DoD  only  makes  up  approximately  0.4%. [7)  Hartshorn]  To  hold 
a  place  in  their  market,  COTS  manufacturers  must  remain  competitive,  which  means  a 
continual  push  in  the  development  and  use  of  technology.  It  is  this  intense  competition 
that  drives  the  fast  technical  update  cycles  and  ultimately  influences  technology  change 
and  direction.  To  this  end,  the  COTS  manufacturer's  position  in  the  marketplace  is 
dependent  on:  the  company  size  and  its  technology  edge.  These  factors  impact  the 
direction  and  update  cycles  of  technology  and  the  products  that  employ  them.  Therefore, 
the  COTS  manufacturers  hold  a  significant  place  in  weapon  system  development  and 
manufacturing  because  they  can  effectively  facilitate  the  quick  response  to  DoD  changing 
needs. 

Typically  DoD  design  and  develop  cycles  span  5  to  7  years  (10-15  years 
historically)  [8)  McDermott]  and  are  expensive  and  often  deploy  out  of  date  equipment. 
COTS  manufacturers  on  the  other  hand  take  a  big  business  approach  in  offsetting 
development  costs  through  economies  of  scale  and  volume  rate  productions.  Therefore, 
they  can  effectively  implement  technology  change  in  a  more  timely  manner.  Through  the 
Acquisition  Reform  Initiatives,  DoD  is  encouraged  to  capitalize  on  these  big  business 
characteristics  and  allow  industry  to  be  burdened  with  the  technology  development  costs. 
The  expected  result  for  DoD  is  lower  overall  developmental  investments  and  an 
opportunity  to  be  able  to  synchronize  their  design  efforts  with  state-of-the-art 
technologies. 
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The  widespread  use  of  COTS  in  military  weapon  systems  does  however  bring 
certain  challenges.  Nothing  is  as  easy  as  it  looks.  There  are  serious  obsolescence  issues 
associated  with  the  use  of  COTS,  as  well  has  other  material  shortages  issue.  The 
challenge  is  to  provide  life  cycle  support  of  fielded  systems  that  use  COTS  products  as 
part  of  the  systems  critical  components.  The  life  cycle  for  some  military  weapon  systems 
may  exceed  20  or  30  years.  This  is  not  at  all  consistent  with  big  business  timelines,  and 
there  is  presently  no  incentive  for  COTS  manufacturers  to  continue  production  of  DoD 
COTS  products  on  a  small  scale.  The  driving  force  here  is  the  market  driven  rate  of 
technology  change  in  the  commercial  world.  In  the  commercial  world  technology 
updates  occur  over  an  18-month  to  2  year  cycle. [8)  McDermott,  9)  Glum,  10)  Robinson] 
By  contrast,  the  DoD  experiences  technology  refresh  cycles  between  5  and  7  years. [8) 
McDermott]  This  cycle  is  impacted  not  only  by  software  and  hardware  updates  but  by 
programmatic  schedule  changes  as  well.  The  challenge  is  further  exacerbated  by  how  the 
military  will  continue  to  develop  weapon  systems  that  do  not  fall  prey  to  technology  that 
will  not  last  or  technology  that  will  undergo  significant  change. 

Technology  changes  will  occur  in  the  COTS  arena  and  will  have  direct  impacts 
on  military  weapon  systems  existing  and  even  those  under  development.  Slight  changes 
in  software  could  have  devastating  effects.  Quite  often  systems  are  built  around 
software,  which  means  systems  architectures  are  dictated  by  software  and  slight  software 
changes  will  likely  have  significant  cost  impacts.  Relatively  small  software  changes 
could  have  very  expensive  consequences.  To  expound  on  the  implication  of  software 
change  impacts,  we  need  to  understand  that  software  may  not  only  dictate  certain 
standards,  but  that  software  changes  occur  fairly  regularly  in  the  commercial  world  and 
re-integration  is  difficult  and  expensive.  The  DoD  has  to  be  aware  of  the  impacts  to 
hardware  due  to  software  changes.  Likewise,  slight  changes  in  COTS  hardware  may 
impact  software  applications.  Additionally,  there  could  likely  be  impacts  in  terms  of 
interfaces  with  other  equipment  or  systems  that  may  not  be  so  apparent.  Subtle 
specification  changes  to  COTS  hardware  (i.e.  timing,  execution...)  could  have 
devastating  ripple  effects.  These  negative  effects  will  be  at  the  system  level  and  will 
substantially  increase  the  risks  associated  with  using  COTS  in  the  future. 
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Since  military  weapon  systems  are  typically  unique,  the  use  of  COTS  becomes  a 
tricky  business  in  tenns  of  dictating  system  design  and  ultimately  life  cycle  support.  In 
tenns  of  software,  military  applications  tend  to  be  very  specific,  and  the  weapon  system 
cannot  tolerate  or  support  changes.  Compatibility  and  configuration-control  become 
crucial  elements  for  both  software  and  hardware.  Support  activities  are  pressured  to 
maintain  stabilized  baselines  in  order  to  keep  the  certification  of  the  system  verifiable. 
These  baselines  include  not  only  the  initial  integration  site  but  also  the  interoperability  of 
fielded  systems  subsequent  to  changes  (i.e.  installation  of  replacement  parts,  firmware, 
software  or  hardware  revisions,  etc..) 

To  fully  understand  this  issue  of  support,  we  must  revisit  certain  DoD 
characteristics.  Military  acquisition  is  characterized  by  high  development  costs  and  very 
long  development  cycles;  therefore  military  procurements  are  forced  to  project  future 
needs  and  purchase  as  many  products  or  components  as  they  think  they  will  need. 
Furthermore,  in  light  of  unique  military  applications,  the  lengthy  life  cycles  and  the  5  to  7 
year  technology  refresh  rate,  DoD  realizes  that  they  presently  have  no  control  over 
product  evolution,  and  therefore  must  compensate  by  staying  aware  of  pending  changes. 
This  awareness  is  critical  if  the  military  is  to  expect  any  appreciable  success  in  support  of 
their  weapon  systems.  Operational  and  maintainability  support  is  expected  over  the 
entire  life  cycle  of  the  system.  This  includes  support  for  design  and  development  efforts 
as  well.  As  mentioned  previously,  DoD  design  and  development  cycles  spanning  10  to 
15  years,  are  expensive  and  often  deploy  out  of  date  equipment.  These  design  and 
development  activities  must  rely  on  commercial  products  to  be  available  when  the  design 
goes  into  production.  Furthermore,  production  and  manufacturing  facilities  must  rely  on 
the  source  of  supply  in  producing  the  systems  they  were  contracted  for,  which  will 
include  commercial  products  that  contain  their  own  supportability  issues. 

The  impacts  of  ineffectiveness  to  support  our  weapon  systems  throughout  their 
life  cycle  will  be  realized  in  military  readiness  and  capability.  When  we  consider  the 
huge  investments  that  DoD  makes  in  getting  technology  to  the  warfighter  and  training 
our  warfighter,  support  of  our  weapon  systems  should  not  be  the  weak  link  in 
maintaining  high  levels  of  combat  readiness  and  personnel  safety.  This  weak  link  might 
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be  the  result  of  the  ever-increasing  pressure  to  reduce  costs.  Very  often  we  hear  of  cost 
as  the  independent  variable  in  design  and  development  efforts  and  that  total  ownership 
costs  should  be  factored  into  the  design  process.  To  do  this  the  design  activities  must 
maintain  a  holistic  perspective  of  the  system  to  include  life  cycle  support  of  technologies 
that  have  been  selected  for  insertion  into  their  weapon  systems. [11)  Osmundson]  With 
the  challenge  of  reducing  costs  and  effectively  supporting  the  warfighter,  today's  systems 
architects  for  DoD  systems  must  understand  what  drives  cost  in  order  to  carefully 
consider  alternatives  for  life  cycle  support. 

The  cost  associated  with  supporting  weapon  systems  throughout  their  life  cycle  is 
perhaps  most  sensitive  to  the  availability  of  components  that  are  needed  to  maintain 
stability  in  the  operational  context.  As  legacy  systems  age,  their  associated  support  and 
maintenance  costs  rise  dramatically  due  to  obsolescence,  reliability  and  supportability 
problems  while  at  the  same  time  the  performance  of  the  system  decreases.  As  original 
equipment  manufacturers  synchronize  their  product  lines  with  technology,  products 
presently  deployed  in  DoD  weapon  systems,  as  well  as  products  intended  for  use  in 
developmental  systems,  will  be  affected.  Alternate  components  or  parts  will  need  to  be 
considered  for  acceptance  or  rejection.  There  will  be  material  shortages  occurring 
because  of  the  social,  economic,  and  political  environments.  In  either  case  there  will  be 
costs  associated  with  these  decisions  and  cost  must  be  managed  effectively.  If  the 
alternate  part  is  accepted,  an  engineering  change  proposal  will  need  to  be  initiated.  There 
is  cost  associated  with  preparation,  coordination,  scheduling  and  testing  of  the  alternate 
part.  If  the  alternate  part  is  unacceptable,  large  product  buys  will  be  needed  to  ensure 
operational  integrity  and  support  of  the  system  over  its  life  cycle.  There  is  cost  with 
developing  a  new  source  of  supply.  In  these  cases  there  are  issues  of  where  to  buy,  how 
much  to  buy,  where  to  stock  them,  and  how  to  manage  the  costs  and  logistical  support  to 
meet  the  needs  of  the  customer. 

Understanding  costs  will  help  government  activities  meet  the  needs  and  desires  of 
the  customer,  mainly  in  assuring  life  cycle  support  of  COTS  products.  More  specifically, 
we  need  to  extend  the  supportability  of  COTS  since  we  know  that  the  life  cycle  of  many 
weapon  systems  exceed  the  life  expectancy  of  the  COTS  used.  By  addressing  the 
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supportability  issue  we  effectively  address  a  much  deeper  need,  that  is  warfighter 
readiness  and  capability.  By  assuring  COTS  supportability  through  the  system's  life 
cycle  we  can  consequently  ensure  reasonable  combat  readiness  and  capability  status.  In 
essence  we  need  to  provide  stability  in  terms  of  baseline  configuration  of  the  weapon 
systems  that  use  COTS  in  order  to  support  the  periods  of  time  between  technology 
refresh  cycles.  That  is  to  say  there  is  a  compelling  need  to  improve  the  supportability  of 
fielded  products  for  the  period  necessary  to  meet  the  user  requirements.  In  satisfying  this 
need,  the  stabilizing  solution/altemative  must  be  cost  effective  at  the  initial  procurement, 
over  the  life  cycle  of  the  system,  and  ultimately  provide  the  lowest  possible  impact  to 
Total  Ownership  Cost  (TOC.)  The  solution  space  will  necessitate  a  predictable  and 
sustainable  process  for  support  of  fielded  and  developmental  systems.  To  be  successful, 
this  process  will  need  to  adequately  identify  risk,  mitigate  those  risks,  and  provide 
resolution  methods  and  planning.  Knowing  now  that  a  new  architecture  is  needed  to 
meet  these  needs  we  must  conclude  that  a  departure  from  traditional  methods  is  necessary 
to  meet  the  challenge  of  sound  planning  and  careful  tailoring  of  COTS  acquisition  at  the 
lowest  possible  cost. 

Reduced  government  funding  and  manpower  levels  have  further  emphasized  the 
need  to  improve  life  cycle  management  processes.  Perhaps  the  focal  point  for  this  effort 
is  COTS  risk  mitigation  during  development  and  for  fielded  weapon  systems.  This  type 
of  continual  assessment  is  needed  to  offset  the  fast  technology  update  cycle  experienced 
in  the  commercial  realm.  Continual  systems  assessment  will  provide  system  baseline 
configuration  stability  and  supportability.  Key  to  success  is  the  need  to  continually 
assess  Original  Equipment  Manufacturers  (OEM)  and  their  COTS  products.  This 
assessment  should  provide  valuable  insight  to  the  vendor's  stability,  which  in  turn 
impacts  the  level  of  risk  associated  with  specific  products  employed  by  DoD.  Such 
assessments  would  perhaps  look  at  how  limited  a  vendor's  product  line  is  and/or  make 
judgments  on  the  potential  of  specific  products  in  that  line  to  change  or  disappear.  To 
this  end,  it  becomes  important  to  detennine  the  likelihood  that  a  vendor  will  continue  to 
provide  DoD  assets  and  the  consistency  of  that  product  line.  The  challenge  is  in  the 
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architecting  of  a  process  that  is  proactive,  disciplined  and  systematic,  that  will  consider 
and  address  the  needs  of  the  customer. 

The  customer  in  this  case  takes  on  many  dimensions. 

The  End  User  -  Certainly  the  end  user  must  be  considered  for  it  is  the  end  user  we 
depend  on  to  operate  our  weapon  systems  and  provide  the  expected  defense  as  defined  in 
our  national  strategic  policies. 

The  Program  Management  Offices  (PMO)  -  This  includes  the  initial  acquisition 
community  whose  purpose  is  the  acquisition  of  new  systems.  They  also  support  the  in- 
service  engineering  activities  that  must  continue  to  procure  parts  as  part  of  an  alteration 
kit  or  on-going  support  for  the  warfighter,  including  repair  and  replacements  of  parts. 
The  PMOs  support  the  Integrated  Logistical  Support  (ILS)  functions,  which  must  plan 
the  long-term  support  of  fielded  equipment  including  changes  to  the  equipment  baseline. 
One  of  the  PMO’s  primary  responsibilities  is  budgetary  support  for  personnel  who  must 
project  the  availability  of  products  that  extend  over  the  2-year  Program  Objective 
Memorandum  (POM)  cycle  and  the  3-5  year  implementation  cycle.  Additionally  the 
PMOs  must  provide  funding  in  support  of  field  activities  or  service  contractors  who 
prepare  Cost,  Health,  and  Risk  models,  which  quantify  the  availability  and  supportability 
of  the  fielded  systems. 

Interoperability  Support  Activities  -  These  activities  must  obtain  and  maintain  a 
stabilized  baseline  in  order  to  keep  the  certification  of  the  system  verifiable.  These 
support  activities  include  not  only  the  initial  integration  site  but  also  the  interoperability 
of  fielded  systems  subsequent  to  changes  (i.e.  installation  of  replacement  parts,  firmware, 
software  or  hardware  revisions,  etc.). 

Design  and  Development  Activities  -  These  activities  must  rely  on  commercial 
products  to  be  available  when  the  design  goes  into  production. 

Production/Manufacturing  F acilities  -  These  facilities  must  rely  on  the  source  of 
supply  of  component  piece  parts  needed  for  producing  the  systems  they  were  contracted 
for,  which  will  include  commercial  products  that  contain  supportability  issues. 
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B.  ECONOMIC  PROBLEM 


The  current  DoD  requirements  include  a  scenario  of  increased  operations  while  at 
the  same  time  a  continuous  push  for  weapon  system  upgrades.  The  easy  solution  would 
be  to  increase  the  defense  budget,  although  not  very  likely.  Given  the  political  pressures 
of  today,  DoD  PMOs  are  challenged  to  search  for  more  economical  alternatives.  The 
challenge,  in  effect,  is  to  maintain  near-tenn  weapon  system  readiness  while  at  the  same 
time  planning  for  weapon  system  modernization  efforts.  To  add  to  this,  DoD  is 
undergoing  a  serious  reduction  in  government  infrastructure.  Given  the  current  trend  of 
increasing  military  operating  tempos,  the  struggle  to  accomplish  any  sort  of 
modernization  effort  is  going  to  be  difficult.  In  fact,  financial  resources  are  likely  to  be 
used  to  maintain  these  levels  of  operations  rather  than  conducting  serious  modernization 
efforts.  The  Joint  Aviation  Logistics  Board  (JALB)  June  1999  report  on  Commercial 
Support  of  Aviation  Systems  states  that  “...discretionary  procurement  accounts  dropped 
by  53  percent  since  1990,  while  operations  and  maintenance  activity  declined  by  only  15 
percent”  [12)  JALB].  The  implication  of  this  statement  is  that  replacement  or  upgrades 
to  existing  systems  are  effectively  being  delayed.  Secretary  of  Defense  William  Cohen,  in 
the  May  1997  Report  of  the  Quadrennial  Defense  Review,  observed  that  “  Today,  the 
Department  is  witnessing  a  gradual  aging  of  the  force.”  [13)  QDR]  This  lends  credence 
to  the  statement  in  a  1994  issue  of  Army  RD&A  Bulletin :  “In  actuality,  our  military 
hardware  is  now  on  a  replacement  cycle  of  about  54  years  -  this  in  a  world  where 
technology  typically  has  a  half-life  from  2  to  10  years.”  [14)  Augustine]  The  end  result 
to  all  of  this  is  that,  existing  systems  will  have  to  be  maintained  at  the  required  levels  of 
availability  and  reliability  for  extended  periods  of  time.  Therefore,  traditional  support 
strategies  will  have  to  be  re-evaluated  to  address  this  phenomenon.  These  traditional 
strategies  typically  expect  total  government  ownership  of  support  material  and  total 
government  control  over  design  changes.  What  this  has  leaded  to  is  known  as  the  COTS 
initiative.  The  emphasis  on  COTS  product  usage  was  brought  on  by  the  fact  that  the  DoD 
could  conceivably  take  advantage  of  technology  developments  in  the  commercial  sector 
at  a  reduced  cost  to  development  programs.  So  given  the  fact  that  more  and  more  of  the 
defense  budget  is  going  to  sustainment  of  operations,  the  financial  resources  needed  to 
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modernize  existing  weapon  systems  is  decreasing.  So  to  reiterate,  support  of  existing 
fielded  systems  at  a  reduced  financial  burden  is  needed  and  one  initiative  meant  to  meet 
this  challenge  is  the  use  of  COTS  products  throughout  DoD  weapon  and  support  systems. 
With  COTS  products  come  additional  challenges  in  support,  given  the  fast  paced 
technology  update  cycles  in  the  commercial  sector  as  compared  to  the  slow  and 
methodical  DoD  acquisition  process.  Thus,  there  is  an  anticipated  increase  in  material  or 
product  obsolescence.  So  the  savings  realized  by  implementing  an  aggressive  COTS 
initiative  could  be  offset  by  obsolescence  and  the  need  to  redesign.  This  is  not  to  say  that 
COTS  products  have  not  proved  beneficial,  on  the  contrary,  but  the  overall  process  for 
incorporation  and  sustainment  of  COTS  products  continues  to  evolve  and  program 
managers  continue  to  be  confronted  with  certain  challenges  associated  with  this. 
Therefore,  a  solution  alternative  is  needed  to  counteract  the  costs  associated  with  the 
redesign  of  weapon  and  support  systems  due  to  obsolescence  rather  than  performance. 

C.  SUSTAINMENT  PROBLEM 

The  COTS  initiative  was  brought  about  by  the  fact  that  the  commercial  sector 
essentially  drives  technology  change  at  an  extremely  fast  paced  and  that  the  DoD  could 
take  advantage  of  this  while  reducing  life  cycle  costs.  The  COTS  initiative  provided  a 
potential  path  to  infuse  new  technology  into  the  military  systems  and  at  the  same  time 
avoid  the  developmental  costs  associated  with  grooming  the  new  technology.  The  rate  at 
which  private  industry  can  develop  and  deliver  new  technologies  is  orders  of  magnitudes 
faster  than  traditional  DoD  acquisitions.  Take  a  look  at  computing  power,  which  has 
appeared  to  double  every  eighteen  months.  The  same  phenomenon  has  occurred  across 
the  spectrum  of  technology  at  different  rates.  Market  forces  other  than  the  DoD 
essentially  drive  this  explosion  of  new  capabilities.  DoD  makes  up  approximately  0.4% 
of  the  market  share;  [7)  Hartshorn]  therefore;  it’s  not  hard  to  see  how  commercial  product 
lines  are  driven  by  the  private  sector  vice  the  DoD.  There  are  two  fundamental  reasons 
for  this  fast  pace.  One  is  the  ever-increasing  demand  for  new  capabilities  primarily  in  the 
private  domain.  Second,  the  competitive  drive  to  get  technology  to  market  first  and  gain 
the  most  lucrative  share  of  the  market.  In  either  case,  DoD  has  little  influence.  Original 
Equipment  Manufacturers  (OEM)  routinely  stop  production  on  items  that  can  no  longer 
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be  justified  from  a  business  perspective  regardless  of  the  impact  to  the  DoD.  The  typical 
length  of  time  a  product  can  be  considered  available  is  approximately  18  months.  That  is 
to  say,  manufacturers  are  developing  and  releasing  new  capabilities  every  1 8  months  to  2 
years.  In  contrast,  DoD  weapon  system  acquisitions  typically  take  10  to  15  years  to 
develop  and  fully  deploy.  At  a  very  minimum,  DoD  can  presently  only  hope  to  achieve 
technology-refresh  cycles  of  5  years,  which  is  still  not  adequately  aligned  with 
commercial  product  updates.  See  Figure  2  for  a  pictorial  representation  of  this 
phenomenon. 


Figure  2:  COTS  vs  NAVY  Refresh  Cycles 

When  we  say  fully  deploy,  we  mean  that  even  though  a  weapon  system  is  ready  to 

be  installed,  each  platform  for  installation  must  be  scheduled  to  receive  it.  Even  if  we 

consider  an  aggressive  development  effort  within  the  Navy,  the  time  to  develop  a  new  or 

enhanced  capability  could  easily  take  5  to  7  years.  Once  the  weapon  system  has  been 

tested  and  deemed  ready  for  deployment,  it  will  take  additional  5  to  10  years  to  fully 

deploy.  Every  platform  or  ship  that  is  to  receive  this  weapon  system  must  be  scheduled 

and  the  work  to  install  performed.  Ship  deployment  schedules  and  the  length  of 

availabilities  (in-port  period  when  the  work  is  performed)  add  serious  delays  to  installing 

the  weapon  system.  It  is  simply  inconceivable  to  think  that  new  technology,  which  is 

turning  over  every  18  months,  can  be  infused  consistently  throughout  the  Fleet.  Of 

course,  its  possible  to  have  different  platforms  upgraded  to  different  levels  of  capability, 

but  then  we  run  the  risk  of  incompatibility  between  platforms  and  a  logistical  nightmare 

in  supporting  various  versions  of  the  same  weapon  system.  What  this  all  comes  down  to, 
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in  terms  of  COTS,  is  a  decrease  in  DoD  control  over  weapon  system  design  and 
subsequent  support.  The  purpose  here  is  not  to  discredit  the  COTS  Initiative  as 
ineffective.  The  COTS  Initiative  in  conjunction  with  a  well  throughout  open  systems 
approach,  will  contribute  greatly  to  DoD’s  effort  to  bring  the  latest  technology  and 
capability  to  the  warfighter  at  the  most  cost  effective  levels  and  be  able  to  sustain  such 
affordably.  The  fact  of  the  matter  is  that,  the  DoD  acquisition  process  is  purposely 
constructed  to  take  a  conservative,  thoughtful  approach  to  implementing  change,  thereby 
introducing  obstacles  to  the  time  elements  necessary  to  keep  pace  with  the  commercial 
environment.  The  most  important  point  to  understand  here  is  the  disconnect  between  the 
life  cycle  of  commercial  products  (1.5  to  5  years)  and  the  typical  reaction  time  of  the 
DoD  for  modernizing  fielded  weapon  systems.  Traditionally,  the  support  strategy  has 
been  to  buy  spares  and  store  them  based  on  a  forecasted  need  over  this  period  of  time.  In 
reaction  to  the  obsolescence  announcement,  the  Program  Office  enters  a  planning  period 
of  between  2  and  3  years.  Following  this  is  a  5  to  7  year  expectation  for  actual 
implementation.  So  we  are  looking  at  approximately  7  to  10  years  between  system 
upgrades  or  replacement  at  a  minimum.  But  now  consider  the  fact  that  these  systems  are 
expected  to  be  in  service  for  15  years  or  more  and  the  supportability  issues  become 
apparent  given  the  consistent  18-month  to  2-year  commercial  technology  life  expectancy. 
In  essence,  when  the  DoD  decides  to  use  COTS  products,  they  become  obsolete  during 
the  planning  phase.  Even  a  well-planned  approach  can  push  COTS  technology  insertion 
into  the  implementation  phase  only  to  become  obsolete  during  this  period  as  well.  This 
instability  to  systems’  design  baselines  is  a  major  issue  for  maintaining  appropriate 
readiness  and  availability.  Understanding  the  realities  associated  with  implementing  and 
supporting  COTS  products,  an  effort  must  be  made  to  deal  with  stabilizing  the  systems’ 
design  baselines  so  high  perfonnance  in  terms  of  support  can  be  achieved. 

D.  COTS  PROBLEM 

The  term  COTS,  Commercial-Off-The-Shelf,  refers  to  the  entire  range  of  products 
and  services  procured  by  the  DoD.  Nearly  every  weapon  system  and  their  basic  repair 
items  use  commercial  items  to  varying  degrees.  Today,  it  is  not  a  matter  of  all  or 
nothing,  but  how  much  of  the  system  is  COTS  based.  Figure  3  is  a  notional  interpretation 
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of  COTS  as  described  in  the  Federal  Acquisition  Regulation  (FAR),  Subpart  2.1, 
Definitions  Section  2.101. 


Commercial 

Item 


(i) 

An  item  for  sale,  lease  or 
license  to  the  general  public 


(2) 

An  item  that  evolved  from 
(1)  that  will  be  available  in 
time 

I 

(3) 

Items  that  are  minor  or 
standard  modifications  of  (1) 
&(2) 


(5) 

Services  procured  for  the 
support  of  (1),  (2),  (3)  & 
(4) 


(6) 

Services  offered  and  sold 
competitively  in  the 
commercial  marketplace  at 
catalog  prices 


I 

(4) 

Any  combination  of  (1),  (2), 
(3),  or  (5)  customarily  sold  to 
the  general  public 


I 

(7) 

Any  of  (1)  thru  (6)  that  have 
been  transferred  from 
another  of  a  contractor’s 
organizations 


(8) 

An  item  sold  competitively 
in  large  quantities  to  local 
and  state  governments 


(1) 

Any  previously  developed  item 
^  used  by  federal,  state,  local,  or 
allied  governments 


Non- 

developmental 

Item 


(2) 

(1)  that  requires  only 
minor  modifications 


(3) 

Integration  of  NDI  subsystems 
and  components 


Figure  3:  COTS  Description  [15)  FAR] 

The  DoD  mandate  for  COTS  product  use  is  driven  by  two  important  situations. 
First,  that  fact  the  commercial  market  leads  the  DoD  in  latest  technology  development; 
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therefore,  in  order  for  the  DoD  to  access  state-of-the-art  technology  they  must  come  to 
the  commercial  sector.  In  the  past  the  DoD  lead  the  way  in  research,  development  and 
application  of  technology  for  military  weapon  systems.  Today  private  industry  leads  the 
DoD  in  these  areas.  Secondly,  the  present  industrial  base  is  very  stable.  That  is  in  the 
face  of  obsolescence,  DoD  suppliers  struggle  to  stay  in  business  due  to  reduced 
procurement  by  the  DoD.  The  larger  companies  have  sufficient  market  share  to  remain 
stable  through  these  periods  of  reduced  DoD  procurement.  Additionally,  they  can 
respond  to  a  surge  in  requirements  by  the  DoD. 

Given  the  widespread  use  of  COTS  products  in  military  weapon  and  support 
systems,  certain  challenges  have  become  evident  in  terms  of  ensuring  long-term 
supportability.  The  challenges  stem  from  serious  obsolescence  issues  and  material 
shortages.  The  challenge,  in  essence,  is  to  provide  life  cycle  support  to  fielded  weapon 
systems  that  use  COTS  products.  Consider  for  a  moment  that  many  systems  will  have 
life  cycles  that  exceed  20  or  30  years,  and  one  can  easily  imagine  the  sustainment 
nightmare  involved.  The  slow  acquisition  process,  the  long  life  expectancies  and 
traditional  support  methods  are  not  consistent  with  commercial  business  practices.  In 
fact,  there  is  little  incentive  for  COTS  manufacturers  to  continue  to  produce  items  in 
rather  small  quantities  just  for  the  sake  of  ensuring  some  system  perfonnance  baselines. 
If  DoD  chose  not  to  use  COTS,  there  would  be  little  impact  to  the  commercial  world. 
However,  given  the  proliferation  of  COTS  products  throughout  military  weapon  systems, 
when  a  product  is  no  longer  produced  the  impacts  to  the  DoD  are  profound  and  severe. 
Even  small  changes  to  a  product  can  have  serious  repercussions  to  weapon  system 
performance  and  design  baselines.  The  fact  of  the  matter  is,  there  will  be  technology 
changes  within  the  COTS  arena  and  they  will  have  direct  impacts  on  military  weapon 
systems,  both  fielded  and  under  development.  Slight  changes  in  COTS  hardware  could 
possibly  impact  interfaces  with  other  equipment  or  systems  that  may  not  be  so  obvious. 
Subtle  specification  changes  to  COTS  hardware  (i.e.,  timing,  execution...)  could  have 
devastating  ripple  effects.  Furthermore,  changes  to  hardware  could,  and  often  do,  require 
changes  in  software  code  in  the  larger  system.  A  change  in  code  translates  into  time  and 
money.  Time  to  make  the  necessary  changes,  test  the  changes,  and  deploy  the  changes 
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and  money  to  perform  these  tasks.  This  is  not  hard  to  understand,  when  you  realize  that 
many  systems  are  built  around  software  (that  is  architectures  that  are  dictated  by 
software).  Software  is  a  key  enabler  to  achieving  open  systems  architecture,  as  software 
is  assumed  easier  to  update  than  hardware.  Nevertheless,  slight  changes  in  software  do 
have  a  cost  associated  with  it  and  the  impacts  could  be  significant.  In  the  face  of  the 
rapid  updates  to  software  in  the  commercial  domain,  DoD  re-integration  efforts  can  be 
difficult  and  expensive.  To  this  end,  the  continue  implementation  of  COTS  products  in 
the  development  of  military  weapon  systems  will  lead  to  a  situation  where  these  systems 
will  constantly  fall  prey  to  technology  that  will  not  last  or  forever  changing. 

E.  THE  CONTRACTING  ENVIRONMENT 

The  DoD  5000  series  documents  require  the  contracting  environment  to  maximize 
competition  and  considers  it  critical  in  providing  innovation,  product  quality, 
affordability  and  reducing  costs  from  both  government  and  industry  providers  alike. 
Through  the  use  of  the  systems  engineering  approach,  an  integrated  acquisition  and 
logistic  process  must  focus  on  Total  Ownership  Cost  (TOC)  or  the  subordinate  Life 
Cycle  Cost  (LCC);  Identifying  supportability  as  a  key  design  and  performance  factors. 
The  OMB  Circular  A-76  requires  through  policy  statements,  the  use  of  competition  to 
enhance  quality,  economy,  and  productivity.  These  enhancements  are  possible  by 
performing  cost  comparisons  of  commercial  activities  performed  by  the  government, 
with  contracted  commercial  activities  from  either  within  the  government  or  from 
industry.  Circular  A-76  is  not  designed  to  simply  contract  out.  Rather,  it  is  designed  to: 
(1)  balance  the  interests  of  the  parties  to  make  or  buy  cost  comparison,  (2)  provide  a  level 
playing  field  between  public  and  private  offerors  to  a  competition,  and  (3)  encourage 
competition  and  choice  in  the  management  and  performance  of  commercial  activities. 

The  foundation  documents,  such  as  OMB  Circular  A-ll  and  A-76,  were  put  in 
place  to  establish  the  performance  based  contracting  methodology,  identify  this  cost 
focus  as  the  primary  discriminating  criteria.  Conversely  the  guidance  documents  put  in 
place  by  Naval  Inventory  Control  Point  (NAVICP)  which  are  used  to  implement  the 
methods,  go  beyond  the  cost  criteria  by  adding  additional  caveats  and  restrictions,  such  as 
an  “all  or  nothing”  involvement,  for  functionally  different  but  related  portions  of  the 


39 


support  effort.  Furthermore  by  dictating  the  allocation  of  certain  functions  to  be 

accomplished  by  specific  entities,  the  guidance  documents  constrain  the  cost  focus  of  the 

foundational  documents  potentially  yielding  to  sub-optimal  results.  The  NAVICP 

implementation  documents  define  three  baseline  assumptions  which  mold  the  contracting 

environment:  1)  awards  a  contract  to  a  single  supplier,  2)  assess  current  in-house 

government  activities/functions  on  past  performance  only,  and  3)  defines  a  government 

employee  and/or  activity  as  sub-contracting  to  a  contractor.  The  singular  contract 

requirement  cannot  be  implemented  within  the  Organic  activities  due  to  built-in 

constraints  defined  by  the  Navy’s  structure.  In  identifying  this  as  a  pivotal  requirement 

the  implementation  documents  define  a  non-competitive  environment  with  respect  to  the 

Organic  activities.  The  second  implemented  baseline  assumption  provides  bias  when 

performing  cost  comparisons.  Central  to  the  decision  making  process  regarding  the 

potential  use  of  a  Perfonnance  Based  Logistics  (PBL)  contract  is  the  development  of  the 

Business  Case  Analysis  (BCA).  The  ground  rules  currently  used  in  developing  the 

baseline  cost  estimates  for  Organic  support  (i.e.  in-house  Navy  support  activity)  uses 

historical  perfonnance  data  and  compares  this  data  with  contractor  proposed  estimates  in 

evaluating  cost  effectiveness  of  the  contractor’s  proposed  cost.  Important  to  notice  is  that 

the  Organic  support  costs  rely  solely  on  the  past  data  and  by  doing  the  analysis  in  this 

manner  three  major  assumptions  are  made:  1)  the  past  performance  data  is  accurate, 

applied  in  an  appropriate  manner,  and  the  data  reflects  current  and  future  perfonnance  of 

the  Organic  activities/functions,  2)  there  are  no  opportunities  to  reduce,  streamline,  or 

improve  the  Organic  cost  figures,  and  3)  the  Organic  activities/functions  would  not  be 

affected  by  the  competitive  environment.  Applying  historical  costs  to  the  Organic 

entities  and  comparing  the  cost  estimates  in  a  proposal  from  the  contractor  yields  a  bias 

in  favor  of  the  contractor.  Although  this  type  of  analysis  is  considered  to  foster  a 

competitive  environment  where  the  lowest  cost  gets  the  contract,  the  process  side  steps 

many  of  the  tenets  of  true  competition.  The  third  baseline  assumption  appears  to  be  in 

direct  conflict  with  the  foundational  documents  for  functions/activities,  which  require  the 

use  of  value  judgments  having  long-term  programmatic  impacts.  The  implementation 

methods  employed  in  developing  performance  based  contracts  handicaps  the  Organic 

activity/function,  identifies  no  method  to  input  into  the  decision-making  criteria, 
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potentially  places  Government  employees  in  a  position  of  having  a  “conflict  of  interest”, 
provides  a  “non  level  playing  field”,  and  in  no  way  assures  the  Navy  receives  the  best 
possible  value  available  in  today’s  market  place. 

The  new  emphasis  in  the  contracting  environment  using  PBL  contracting 
methodologies  presents  challenges  to  the  Organic  activity/functions  with  respect  to 
implementing  the  SSB  system.  It  appears  evident  that  these  challenges  include:  1)  a 
barrier  to  entry  into  the  PBL  contracting  environment  due  to  exclusionary  policies  at  the 
contract  implementation  level  (NAVICP  level)  although  the  upper  level  policies  support 
the  SSB  systems  concepts,  2)  the  current  contracting  methodologies  establish  scenarios  in 
which  there  could  be  a  “conflict  of  interest”  for  Government  employees  when  providing 
sub-contracting  services  for  a  contractor,  this  potential  could  directly  impact  the  SSB 
system  applicable  since  it  is  performed  by  Organic  activities/functions,  and  3)  no 
definition/designation  is  provided  with  regards  to  the  DMSMS  support  function  and  its 
categorization  as  an  “inherently  Governmental  function”  or  a  commercial  activity, 
without  such  an  identification  there  exists  an  amount  of  uncertainty  about  who  would  be 
performing  the  SSB  systems  functions  in  the  future.  The  purpose  of  this  section  is  to 
identify  and  describe  the  factors,  which  could  influence  the  success  of  the  SSB  system  in 
the  current  market  place.  Responses,  adjustments,  and/or  resolution  to  the  challenges 
described  above  are  addressed  in  the  Marketing  Plan. 

F.  CURRENT  STAKEHOLDER  ASSESSMENT 

Program  Management  Office  (PMO)  -  The  PMO  through  its  Integrated  Logistics 
Support  (ILS)  group  orders  COTS  assemblies  through  the  normal  support  systems  by 
contract,  purchase  order,  or  Navy  supply  system.  If  an  OEM  no  longer  supports  a 
product,  then  the  PMO  must  look  for  another  avenue  to  solve  the  issue,  typically  an 
engineering  analysis  and  review  is  necessary  yielding  a  variety  of  solutions  most  of 
which  are  very  expensive.  If  the  PMO  is  lucky  or  just  well  informed  (which  is  not 
always  the  case),  the  OEM  will  provide  a  notice  stating  an  “End  Of  Life”  (EOL)  date 
after  which  the  OEM  will  no  longer  support  the  specific  COTS  product.  At  this  point  the 
Program  Office  must  make  some  choices.  Regardless  of  the  choices  made,  the  Program 
Office  incurs  a  significant  amount  of  risk  usually  at  a  hefty  price. 
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Original  Equipment  Manufacturer  ( OEM)  -The  OEM  is  usually  a  leading  edge 
technology/design  firm  that  is  market  driven  and  produces  at  high  volume  and  cost 
reflective  of  commercial  economies  of  scale.  The  fast  paced  environment  requires  short¬ 
lived  products  (-18-24  months)  to  keep  up  with  the  ever-changing  technology.  The 
business  case  is  just  not  there  to  cater  to  the  DoD/govemment’s  needs  and  although  the 
OEM  wishes  to  keep  this  group  of  consumers,  the  momentum  of  the  business  cycle  keeps 
the  OEM  focused  elsewhere.  Under  these  circumstances  supportability  is  limited  to 
production  run  time  (-18-24  months)  with  approximately  a  12-month  follow-on  repair 
and  test  capability  period. 

Small  Business  (SSB  Supplier)  -  The  SSB  supplier  is  envisioned  to  come  from  the 
large  base  of  smaller  suppliers  who,  over  the  past  three  decades,  have  provided  the 
DoD/government  with  high  technology  custom  products.  Using  this  supplier  base  will 
reduce  the  risk  caused  during  the  technology  transfer  process  because  of  the  proven  track 
record  earned  when  dealing  with  other  DoD/government  products.  However,  this  will  be 
a  collaborative  process  and  the  final  decision  will  reside  with  and  between  the  OEM  and 
the  SSB  supplier.  Here  the  OEM  holds  the  trump  card  and  must  be  willing  to  live  with 
the  choice.  The  small  business  SSB  supplier  typically  has  extensive  technical  know  how 
in  the  manufacturing  area  but  lacks  the  expertise  to  accomplish  proactive,  predictive 
obsolescence  management.  These  companies  are  customer  focused,  agile,  and  seek  long¬ 
term  relationships  with  their  customers. 

DoD  Navy  Activities/Resources  -  Most,  if  not  all,  of  the  needed  functions  required 
by  the  SSB  system  are  already  accomplished  by  internal  DoD/government  resources; 
however  they  are  done  in  an  ad-hoc  fashion  without  the  collaborative  environment,  and 
with  no  defined,  supportable,  and  repeatable  process  in  place.  The  expertise  has  always 
been  available  in  the  DoD/government  but  in  a  different  form  using  a  different  process. 
Prior  to  Acquisition  Refonn,  the  MIL-Specs  and  Standards  provided  a  requirements-rich 
environment  with  well-defined  processes  for  implementation.  These  processes  and 
implementation  methods  required  the  same  expertise  needed  today  but  applied  in  a 
different  context.  Today’s  environment  is  requirements-poor,  and  the  talented  expertise 
must  adjust  to  this  performance-based  versus  MIL-Spec-based  environment.  The  context 
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in  today’s  environment  is  relationship-based,  not  rule-base,  and  the  survivability  of  this 
entire  group  of  talented  experts  will  depend  on  their  adaptability  to  today’s  context. 
Acquisition  Reform  removed  the  barriers  put  in  place  by  the  MIL-Spec,  rule -based 
environment,  but  it  failed  to  provide  an  adequate  substitute,  which  would  provide  a 
robust  process  that  can  meet  the  supportability  requirements  and  needs  of  the  end  user. 
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III.  RESEARCH  METHODOLOGY 


A.  INTRODUCTION 

The  research  methodology  taken  to  develop  the  SSB  system  required  the  design 
and  development  of  four  independent  documents  coupled  with  implementation  activities 
to  exercise  the  concepts  being  incorporated  into  the  system  infrastructure.  The  four 
documents  (Appendixes  A-D  to  this  thesis  paper)  are  as  follows: 

•  Appendix  A  -  The  Sunset  Supply  Base  Architecture 

•  Appendix  B  -  The  Systems  Engineering  Development  and  Implementation 
(SEDI)  Plan 

•  Appendix  C  -  The  Business  Case  Analysis  (BCA) 

•  Appendix  D  -  The  Marketing  Plan 

Each  of  the  four  appendixes  are  written  as  standalone  documents  for  use  as 
independent  ready  reference  materials  for  a  specific  area  of  interest.  The  purpose  of  this 
segmentation  of  the  systems  development  was  to  provide  a  meaningful  resource  to  the 
functional  groups,  who  will  need  the  background  infonnation  regarding  the  SSB  system, 
in  an  encapsulated  set  of  characteristics  gennane  to  a  specific  area.  For  example,  the 
SSB  Systems  Architecture  will  be  of  interest  to  PMO  support  groups  like  Integrated 
Logistics  Support  (ILS)  groups,  who  will  be  interested  in  the  relationship  management 
areas  between  the  OEM,  the  Sunset  Supplier,  procurement  activities,  and  Navy  support 
activities.  The  Systems  Architecture  provides  an  outline  of  these  relationships  and  the 
reasons/logic  behind  their  development.  The  SSB  Architecture  provides  the  initial 
structural  elements  and  base  relationships  needed  in  development  of  the  SSB  system. 
The  SEDI  plan  provides  the  “How,  Why,  When,  Where,  What”  involved  with  the  SSB 
system  implementation  process  with  the  additional  insight  provided  in  the  form  of 
“Lessons  Learned”.  The  BCA  presents  a  roadmap  to  assess  the  SSB  implementation 
efforts  and  uses  actual  data  from  a  Navy  program  to  illustrate  the  utility  of  the  analysis 
method  and  the  expected  outcome  from  the  SSB  implementation  process.  The  Marketing 
Plan  describes  strengths  and  weaknesses  of  the  SSB  system  and  provides  useful  graphical 
and  tabular  information  to  help  examine  the  usability  of  the  system  to  a  current  or 
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candidate  program.  The  SSB  Systems  Architecture  and  the  SEDI  Plan  constitute  the 
primary  research  methodologies  used  to  develop  the  SSB  system.  The  BCA  and  the 
Marketing  Plan  were  developed  as  part  of  the  analysis  task  of  the  SSB  system  and  as  such 
are  covered  in  detail  in  the  “Data  Analysis”  portion  of  this  thesis  paper.  However  to 
assure  complete  coverage  of  the  research  methodologies  employed  a  detailed  description 
of  the  Systems  Architecture  and  the  SEDI  Plan  are  provided  below. 

B.  APPROACH  SUMMARY 

The  development  of  the  four  documents  parallels  the  sequential  path  that  was 
followed  in  the  SSB  system  development  process.  The  research  methodology  used  in  the 
SSB  system  development  can  be  described  at  a  very  high  level  as: 

•  Identifying  current  status  regarding  COTS  supportability,  defining  up-stream 
and  down  stream  system  requirements,  capturing  customer 
needs/expectations,  perfonning  a  gap  analysis  current  status  versus  customer 
needs,  then  defining  a  Systems  Architecture  (Appendix  A)  to  encompass  the 
identified  expectations  and  constraints. 

The  output  products  of  the  Systems  Architecture  (SA)  generation  were  then  taken 
and  implemented  on  three  Navy  programs.  Since  the  SA  provided  a  roadmap  on  what 
needed  to  be  accomplished  but  lacked  the  details  on  how  to  get  the  system  functional,  the 
implementation  step  proved  invaluable  in  addressing  these  concerns.  The  Systems 
Engineering  Development  and  Implementation  (SEDI)  Plan  (Appendix  B)  uses  the 
“Functional  Flow  Diagram”-  Figure  4  -  and  the  “Informational/Data  Flow  Support 
Structure”  -  Figure  5,  as  the  primary  outputs  of  the  SA  effort.  These  output  products 
were  refined  in  the  SEDI  plan  and  renamed  as  the  “17  Step  Process”  and  the 
“Obsolescence  Impact  &  Purchase  Request  Report”  respectively.  The  SEDI  plan 
identifies  four  primary  implementation  products  and  four  major  output  products.  The 
implementation  products  provide  insight  to  the  implementing  process  as  a  risk 
management  tool  while  the  output  products  provide  decision  quality  information  for 
identifying  the  “best  value”  alternatives  for  the  Navy. 

The  data  collected  during  the  SEDI  step,  needed  to  be  transformed  into  usable 
information  and  knowledge,  this  task  was  accomplished  through  development  of  the 
Business  Case  Analysis  (BCA)  (Appendix  C).  As  a  primary  input  the  BCA  used  the 
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“Assembly  Master  &  Cost  Matrices”  output  from  the  SEDI  plan,  which  provided  the  raw 
data  for  analysis.  This  raw  data  was  embellished  with  resource  modeling  data  provided 
by  NSWC  Crane’s  “Cost  Model.”  The  BCA  in  turn  produced  a  series  of  tabular  and 
graphical  representations  of  the  financial  impact  due  to  the  SSB  system  implementation. 
An  additional  evaluation  was  performed  describing  non-financial  impacts  showing  some 
of  the  emergent  properties  and  opportunities  produced  through  the  SSB  system. 

Once  the  development  roadmap,  the  implementing  processes  and  products  had 
been  defined,  the  next  logical  step  was  to  incorporate  these  elements  of  the  SSB  system 
in  a  package  that  could  be  easily  disseminated  through  out  the  Navy’s  using  community. 
The  Marketing  Plan  (Appendix  D)  evaluates  the  characteristics  of  the  SSB  system  in  term 
of  its  strengths,  weaknesses,  opportunities,  and  threats,  then  provides  a  plan  of  action  to 
capitalize  on  these  attributes  to  provide  “best  value”  to  the  Navy.  The  SSB  system 
represents  a  Systems  Engineering  approach  to  solving  the  COTS  supportability  risks  and 
as  such  defines  an  overarching  system  instead  of  limited  point  solutions.  One  of  the 
major  products  produces  in  the  Marketing  plan  is  a  graphical  depiction,  which  compares 
COTS  supportability  point  solutions  to  the  attributes  available  through  the  SSB  system. 
The  point  solution  approach  is  currently  the  standard  practice  used  by  the  PMO  DMSMS 
support  groups. 

C.  APPROACH  DETAILS  FOR  THE  SYSTEMS  ARCHITECTURE  AND 

SEDI  PLAN  DEVELOPMENT 

1.  The  SSB  Systems  Architecture  (SA) 

The  approach  taken  to  develop  the  SSB  System  Architecture  (SA)  required  a 
series  of  detailed  evaluations  to  yield  an  understanding  of  the  current  environment  and 
employed  methods  to  address  the  COTS  supportability  issues.  The  premise  for  this 
developmental  effort  was  the  expectation  that  the  end  result  would  be  an  immediately 
usable  product/system  for  the  Navy.  Therefore  the  developed  system  must  work  with  and 
leverage  as  much  as  possible,  the  processes  and  practices  used  currently  to  support  the 
Navy’s  systems.  Detailed  analysis  is  provided  in  Appendix  A  regarding  the  current  status 
of  COTS  supportability  for  the  Navy’s  system  and  their  “cause  and  effect”  relationship  to 
the  warfighter.  The  approach  used  to  distill  these  independent  support  practices/methods 
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into  a  cohesive  system  required  the  use  of  some  engineering  judgments  and  the  use  of  a 
set  of  well-established  heuristics  (base  rules).  A  list  of  the  primary  judgments/heuristics 
[11)  Osmundson,  16)  Maier-Richtin]  used  to  guide  the  development  process,  are  as 
follows: 


•  Employ  a  holistic  view. 

•  A  complex  system  will  develop  and  evolve  within  an  overall  architecture 
much  more  rapidly  if  there  are  stable  intermediate  forms. 

•  Using  an  evolutionary  approach  from  current  practices/methods  as  a  baseline 
a  spiral  development  process  will  assure  the  developed  system  answers  the 
right  problem. 

•  The  greatest  dangers  are  at  the  interfaces. 

•  Interoperable  “Systems  of  Systems”  will  yield  new  and  emergent  properties 
which  are  greater  than  the  sum  of  the  independent  systems. 

•  Design  the  structure  with  good  bones. 

•  Consider  a  collaborative  system  a  franchise.  Always  ask  why  the  franchisees 
choose  to  join,  and  choose  to  remain. 

•  The  system  is  collaborative  in  the  sense  that  the  members  are  assembled  and 
operate  through  the  voluntary  choices  of  the  participants,  not  through  the 
dictates  of  an  individual  client. 

•  If  the  politics  do  not  fly,  the  hardware  never  will. 

•  The  emergent  capability  is  the  whole  point  of  the  system;  but  the  architect 
may  only  be  able  to  influence  the  interfaces  among  the  nearly  independent 
parts,  the  components  are  outside  the  scope  and  control  of  an  architect  of  the 
whole. 

•  Members  (Navy  activities)  participating  in  a  collaborative  system  must 
understand  that  their  efforts  are  not  based  on  a  “zero  sum  end  game”  that  the 
gain  of  capabilities  by  one  activity  by  using  the  collaborative  system  does  not 
subtract  capability  from  any  other  activity.  The  new  emergent  properties  of 
the  system  provide  a  “Win-Win”  scenario. 

a)  Primary  Output  Products  of  the  Systems  Architecture 

The  two  primary  output  products  from  the  Systems  Architecture  are 
provided  below  as  -  the  “Functional  Flow  Diagram”-  Figure  4  -  and  the  “Informational/ 
Data  Flow  Support  Structure”  -  Figure  5.  The  “Functional  Flow  Diagram”  provides  a 
high  level  sequential  set  of  steps  to  follow  in  establishment  of  the  SSB  system.  The 
“Informational/Data  Flow  Support  Structure”  shows  the  necessary  infonnation  flow  and 
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associated  relationships  needed  to  support  the  SSB  system  once  in  place.  At  the  core  of 
this  collaborative  approach  is  the  management  of  interfaces.  The  planned  development 
of  the  standalone  SSB  system  from  the  overarching  system,  comprised  of  existing  key 
entities,  constitutes  a  collaborative  architecture.  Because  the  function  and  form  of  these 
existing  entities  is  already  defined  and  all  operate  as  independent  systems,  interfaces 
between  these  entities  become  critical  for  effective  collaboration.  Thus,  interface 
management  is  an  important  discipline  that  must  be  implemented  in  order  for  the  SSB 
system  to  be  successful.  A  means  of  effective  interfacing  is  also  crucial  to  the  success  of 
this  system.  Therefore  following  the  graphical  representations  (Figures  4  &  5)  a  textual 
description  of  current  practices/methods  and  proposed  practices/methods  is  provided 
from  the  different  participants  viewpoints.  These  products  provide  the  starting  point  and 


baseline  from  which  the  implementation  efforts  may  begin. 


Figure  4:  Functional  Flow  Diagram 
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Figure  5:  Information/Data  Flow  Support  Structure 

2.  Impacts  of  SSB  Implementation 

Program  Management  Office  (PMO) 

Current:  The  PMO  through  its  Integrated  Logistics  Support  (ILS)  group  orders 
COTS  assemblies  through  the  normal  support  systems  by  contract,  purchase  order,  or 
Navy  supply  system.  If  an  OEM  no  longer  supports  a  product,  then  the  PMO  must  look 
for  another  avenue  to  solve  the  issue,  typically  an  engineering  analysis  and  review  is 
necessary  yielding  a  variety  of  solutions  most  of  which  are  very  expensive.  If  the  PMO 
is  lucky  or  just  well  informed  (which  is  not  always  the  case),  the  OEM  will  provide  a 
notice  stating  an  “End  Of  Life”  (EOL)  date  after  which  the  OEM  will  no  longer  support 
the  specific  COTS  product.  At  this  point  the  Program  Office  must  make  some  choices. 
Regardless  of  the  choices  made,  the  PMO  incurs  a  significant  amount  of  risk  usually  at  a 
hefty  price. 


Proposed:  The  collaborative  process  is  illustrated  using  two  notional  graphic 
Figures  (4  &  5)  to  show  the  relationship  and  informational  interfaces  between  the  PMO 
and  the  other  identified  players.  Figure  4  shows  the  process  flow  at  a  functional  level 
delineating  the  relationship  each  player  has  to  the  others  during  the  SSB  development. 
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As  a  collaborator  in  this  process,  the  Program  Office  provides  the  funding  resources  to 
internal  government  activities  to  facilitate,  assess,  and  report.  Also,  the  PMO  is  agreeing 
to  pay  for  the  royalty  and  provide  the  Bill  Of  Material  (BOM).  For  their  efforts  the  PMO 
receives:  1)  an  alternate  long  term  supplier  of  the  COTS  product  and  a  relationship  with 
that  supplier  and  their  associated  OEM  that  may  be  extended  for  other  OEM  discontinued 
items,  2)  as  identified  in  Figure  5,  a  continuous  update  to  the  risk  identification  and 
mitigation  efforts,  proactively  adjudicating  obsolescence  issues  seamlessly  on  behalf  of 
the  PMO,  3)  provides  the  PMO  with  a  corporate  knowledge  data  base  on  which  future 
decisions  can  leverage,  4)  although  not  identified  through  the  figures,  the  program  gains 
reparability  and  testability  attributes  over  the  life  cycle  of  the  system  defined  by  the 
Navy’s  needs.  The  method  of  communication  being  online  is  nearly  in  real  time  so  the 
effort  expended  by  the  PMO  is  minimal.  Product  ordering  is  done  using  current 
procurement  methodologies. 

Original  Equipment  Manufacturer  (OEM) 

Current:  The  OEM  is  usually  a  leading  edge  technology/design  firm  that  is 
market  driven  and  produces  at  high  volume  and  cost  reflective  of  commercial  economies 
of  scale.  The  fast  paced  environment  requires  short-lived  products  (-18-24  months)  to 
keep  up  with  the  ever-changing  technology.  The  business  case  is  just  not  there  to  cater  to 
the  DoD/govemment’s  needs  and  although  the  OEM  wishes  to  keep  this  group  of 
consumers,  the  momentum  of  the  business  cycle  keeps  the  OEM  focused  elsewhere. 
Under  these  circumstances  supportability  is  limited  to  production  run  time  ( — 18-24 
months)  with  approximately  a  12-month  follow-on  repair  and  test  capability  period. 

Proposed:  The  OEM  for  their  part  in  the  collaboration  effort  has  a  lot  to  gain  and 
little  to  lose.  There  is  a  business  case  to  be  made  for  making  a  profit  from  their 
intellectual  property  they  no  longer  find  useful.  The  5-15%  royalty  is  the  incentive,  but 
other  non-tangible  benefits  enhance  the  business  aspects  in  favor  of  the  collaboration 
effort.  Protection  of  their  proprietary  design  is  an  inherent  part  of  the  SSB  process 
through  “Non-Disclosure  Agreements  (NDA)”  and  contractual  mechanisms.  Important 
to  note  is  that  the  contractual  arrangements  are  made  with  another  company,  the  SSB 
supplier,  not  the  government,  which  many  OEMs  find  favorable  since  governmental  red 
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tape  would  poison  the  business  case.  This  situation  leaves  the  ownership  and  control  of 
the  commercial  products  in  the  hands  of  the  industry.  Additionally,  the  government  does 
not  have  to  pay  for  the  design  only  the  product,  a  tenet  of  Acquisition  Reform.  By 
participation  in  the  collaborative  system  the  OEM  establishes  a  long-term  relationship 
with  the  DoD/government  without  the  ongoing  supportability  issues.  In  turn  these  new 
emergent  properties  of  the  system  can  be  used  to  enhance  the  ability  of  the  OEM  to 
market  enhanced  product  supportability,  not  only  to  the  DoD/government  environment, 
but  also  any  entity,  which  is  configuration  constrained  due  to  the  business  constraints  (i.e. 
refineries,  paper  mills,  electrical  power  generation  and  control  applications,  etc.).  The 
OEM  efforts  are  concentrated  during  the  establishment  of  the  SSB  supplier  and  play  a 
crucial  part  in  assuring  that  the  OEM  reputation  will  be  in  safe  hands  when  the  SSB 
supplier  delivers  products.  The  OEM  however  does  agree  to  allow  the  internal  Navy 
resources  visibility  into  the  products  design  by  letting  the  SSB  supplier  share  the  parts  list 
complete  with  associated  component  vendor  information  along  with  a  top  level  assembly 
drawing.  This  is  information  the  government  has  not  been  privy  to  in  the  past  but  it  is 
essential  for  accomplishment  of  risk  analysis  and  yielding  the  desired  emergent 
properties  of  the  system. 

SSB  Supplier 

Current:  The  SSB  supplier  is  envisioned  to  come  from  the  large  base  of  smaller 
suppliers  who,  over  the  past  three  decades,  have  provided  the  DoD/government  with  high 
tech,  custom  products.  Using  this  supplier  base  will  reduce  the  risk  caused  during  the 
technology  transfer  process  because  of  the  proven  track  record  earned  when  dealing  with 
other  DoD/government  products.  However,  this  will  be  a  collaborative  process  and  the 
final  decision  will  reside  with  and  between  the  OEM  and  the  SSB  supplier.  Here  the 
OEM  holds  the  trump  card  and  must  be  willing  to  live  with  the  choice.  The  small 
business  SSB  supplier  typically  has  extensive  technical  know  how  in  the  manufacturing 
area  but  lacks  the  expertise  to  accomplish  proactive,  predictive  obsolescence 
management.  These  companies  are  customer  focused,  agile,  and  seek  long-term 
relationships  with  their  customers. 
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Proposed:  As  for  their  part  in  the  collaboration  process,  the  SSB  supplier  must  be 
willing  to  be  contractually  bound  by  the  agreement  with  the  OEM  and  at  the  same  time 
be  willing  to  work  the  internal  government  resources  to  coordinate  and  facilitate 
supportability  efforts  while  reducing  risk  to  the  program.  Actions  required  by  the  SSB 
supplier  will  include: 

•  sharing  the  OEM  parts  list  and  drawings, 

•  be  the  purchaser,  stock  handler,  and  storage  facility  for  parts  that  have  gone 
obsolete  and  are  awaiting  consumption  once  an  assembly  order  is  placed, 

•  as  requested  by  the  program,  be  willing  to  stock  all  up  assemblies  (which  have 
already  been  paid  for)  to  enable  immediate  turnaround  times  of  fielded 
assemblies  which  have  failed, 

•  accept  all  the  responsibility  for  being  the  prime  supplier  of  the  subject 
assembly. 

In  return  for  its  efforts  the  SSB  supplier  is  rewarded  through: 

•  a  new  relationship  with  a  pre-eminent  commercial  firm, 

•  a  new  product  line, 

•  new  customers,  DoD/govemment  and  non-government, 

•  long  term  relationships  with  the  new  customers  which  enables  long  term 
business  planning, 

•  technical  partnering  with  internal  DoD/govemment  resources  not  only  for 
predictive  obsolescence  management  but  a  whole  host  of  other  specialties. 

Internal  DoD/Government  Resource: 

Current:  Most,  if  not  all,  of  the  functions  identified  in  Figure  4  are  already 
accomplished  by  internal  DoD/government  resources;  however  they  are  done  in  an  ad- 
hoc  fashion  without  the  collaborative  environment,  and  with  no  defined,  supportable,  and 
repeatable  process  in  place.  The  expertise  has  always  been  available  in  the 
DoD/government  but  in  a  different  form  using  a  different  process.  Prior  to  Acquisition 
Reform,  the  MIL-Specs  and  Standards  provided  a  requirements-rich  environment  with 
well-defined  processes  for  implementation.  These  processes  and  implementation 
methods  required  the  same  expertise  needed  today  but  applied  in  a  different  context. 
Today’s  environment  is  requirements-poor,  and  the  talented  expertise  must  adjust  to  this 
performance-based  versus  MIL-Spec-based  environment.  The  context  in  today’s 
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environment  is  relationship-based,  not  rule-base,  and  the  survivability  of  this  entire  group 
of  talented  experts  will  depend  on  their  adaptability  to  today’s  context.  Acquisition 
Reform  removed  the  barriers  put  in  place  by  the  MIL-Spec,  rule-based  environment,  but 
it  failed  to  provide  an  adequate  substitute,  which  would  provide  a  robust  process  that  can 
meet  the  supportability  requirements  and  needs  of  the  end  user. 

Proposed:  The  internal  DoD/govemment  resources  have  a  very  crucial  role  to 
play  regarding  the  supportability  of  all  our  systems  from  design  to  fielded  systems. 
Supportability  is  an  inherently  governmental  function  for  several  reasons:  1)  the 
motivation  of  our  internal  resources  is  in  support  of  the  end  user  needs;  this  perpetuates 
and  enhances  our  positions  and  esteem,  2)  due  to  the  overarching  scope  and  the  long  term 
broad  based  characteristics  of  supportability  issues,  no  one  prime  contractor  could, 
without  conflict  of  interest,  accomplish  these  functions,  and  3)  No  entity  has  or  even 
wishes  to  obtain  the  corporate  knowledge  maintained  by  our  internal  resource  pool.  The 
collaborative  environment  as  is  evident  in  Figures  4  &  5  imbeds  the  talented  expertise 
into  the  SSB  process  in  a  way,  which  leverages  these  resources  and  creates  a  value  stream 
for  the  program.  The  relationship  building  characteristics  of  our  internal  resources  is 
very  evident  in  Figure  5  where  this  crucial  resource  takes  “center  stage”  in  enabling  the 
collaborative  system.  Taking  both  figures  (4  &  5)  in  concert  it  is  easy  to  see  how  the 
resource  can  gain  program  equity  and  support  by  reducing  Total  Ownership  Cost  (TOC), 
extend  supportability  of  systems,  and  reducing  program  risk. 

3.  The  Systems  Engineering  Development  and  Implementation  (SEDI) 
Plan 

The  SEDI  plan  is  structured  in  three  sections:  Infrastructure,  Implementation,  and 
Measuring  &  Assessing.  The  approach  is  intentionally  focused  on  supporting  the 
person(s)  actually  performing  the  implementation  function.  Insight  into  the  process  is 
provided  by  specific  examples  called  “Implementation  Experience”  and  embellished  by 
“Lessons  Learned”  to  help  enable  the  implementing  process.  The  tools,  methods,  and 
processes  described  are  illustrated  through  actual  examples  where  these  practices  were 
used  to  implement  the  SSB  system  on  three  Navy  programs.  These  tools,  methods,  and 
processes  are  provided  in  detail  in  the  enclosures  so  that  they  may  be  used,  not  only  for 
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guidance  but  also  for  a  reusable  template  for  future  work.  A  graphical  depiction  of  the 
implementation  process  is  provided  in  Figure  6  -  Implementation  Process  -  and  was  put 
into  practice  to  generate  the  implementation  and  output  products  of  the  SEDI  plan. 
Description  of  these  products,  are  shown  below  and  are  used  as  the  input  raw  data  to  the 
Business  Case  Analysis  (BCA)  and  Marketing  Plan. 

The  SSB  system  comprises  several  processes  during  the  implementation  of  the 
concept.  As  identified  in  Figure  6  “Implementation  Process”,  a  relationship  building 
process  is  established  to  obtain  the  COTS  component  information  from  the  Original 
Equipment  Manufacturer  (OEM)  for  analysis.  Arrangements  are  made  at  this  time  to 
involve  a  third  party  to  continue  manufacturing  the  products  if  the  OEM  chooses  not  to 
continue  making  the  products.  However  if  the  OEM  wishes  to  participate  by 
continuation  of  production  of  the  COTS  products  and  share  the  risk  of  stockpiling 
obsolete  parts,  then  the  dashed  box  in  Figure  6  identifies  the  scope  of  their  participation. 
The  component  infonnation  is  then  analyzed  for  obsolescence  risk  and  an  assessment  is 
provided  to  the  DMSMS  support  team  to  detennine  the  appropriate  action  plan. 
Typically  the  number  of  high  risk  parts  are  defined  along  with  an  estimated  quantity  of 
each  part  needed  to  support  the  program  fielded  equipment  for  a  prescribed  period  of 
time,  usually  until  the  next  tech  refresh/insertion.  These  parts  are  then  stocked  on  the 
OEM  or  third  parties  shelves  until  they  are  consumed  to  make  the  COTS  assemblies 
needed  in  the  Fleet.  Dependent  on  the  programs  needs  this  process  provides  long-term 
support  for  the  end  user,  the  Fleet. 
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Long  Term  COTS  Support 


Figure  6:  Implementation  Process 

4.  Primary  Output  Products  of  the  SEDI  Plan 


The  SSB  system  provides  a  structured  set  of  processes,  methods,  and  tools 
embedded  in  the  System  Architecture  based  on  a  collaborative  framework.  Although  the 
SSB  system  yields  many  sub-products,  discussed  below,  the  SEDI  plan  is  focused  on  the 
SSB  system  as  the  product  provided  to  the  customer  and  as  part  of  the  system  the  sub¬ 
products  identified  herein  make  up  a  portion  of  that  system.  The  SSB  system  employs 
information  and  risk  sharing,  relationship  building,  and  long-term  planning  to  yield 
definable,  measurable,  and  reportable  impacts  to  fielded  systems.  The  customers  (PMO 
and  support  teams)  consider  both  the  implementing  of  the  SSB  system  and  the  report 
outputs  of  the  SSB  system  as  products.  As  such,  the  implementing  processes  such  as 
information  and  risk  sharing  directly  impact  the  qualitative  output  assessments  like  the 
obsolescence  risk  of  COTS  products  in  fielded  systems.  The  customers  expectations 
include  visibility  into  the  processes  and  qualitative/quantitative  assessments  that 
accurately  define  the  subsequent  output  of  the  process.  To  meet  these  expectations  we 
have  developed  the  following  implementation  and  output  products: 

1)  Implementation  Products 
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a.  Status  Metrics  on  the  17  Step  Process  -  Vendor  Status  Report 

b.  Documented  17  Step  Process 

c.  Prioritized  COTS  List  &  Vendor  Information 
2)  Output  Products 

a.  Obsolescence  Health  Report 

b.  High  Risk  (RED)  Component  List 

c.  Obsolescence  Impact  &  Purchase  Request  Report 

d.  Assembly  Master  &  Cost  Matrices,  with  Definition  Worksheet 

The  implementation  products  provide  the  insight  to  the  customer  regarding  the 
qualitative  assessment  of  programmatic  risk  with  respect  to  the  relationship  building, 
information  sharing,  and  risk  management  practices  employed.  The  output  products 
organize  the  data  and  information  gathered  then  assesses  the  potential  impacts  and 
recommends  proactive  actions  to  mitigate  programmatic  risks.  These  processes,  methods 
and  tools  are  quantitative  in  nature  and  are  presented  in  a  fonnat  to  provide  input  directly 
into  the  business  and  program  management  processes.  Collectively  these  products 
represent  new  knowledge  and  options  for  the  PMO  and  support  team.  Furthermore  the 
modeling  and  simulation  tools  give  the  decision  makers  the  opportunity  to  make  side-by- 
side  comparisons  of  different  potential  candidate  recommendations  prior  to  making  the 
final  decision. 

Implementation  Products 

a)  SEDI  Context:  Enclosure  (17)  “17  Steps ”  -  SSB 

Implementation  Process 

The  “17  Steps”  SSB  system  implementation  process  was  first  described  in 
the  System  Architecture  as  a  method  to  describe  and  document  the  list  of  sequential  steps 
needed  to  implement  the  SSB  system.  These  steps  provide  a  notional  depiction  of  the 
SSB  implementation  process  and  are  supplemented  with  a  set  of  definitions.  These 
figures/definitions  are  also  provided  as  enclosures  for  use  by  new  implementers  to  assure 
consistency  and  repeatability  of  the  process  (see  Enclosures  (17)  &  (18)). 
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b)  SEDI  Context:  Enclosure  (23)  Vendor  Status  Report 

The  parts  lists  came  in  from  the  different  OEMs  at  various  times 
depending  on  the  time  of  interface  with  the  OEM  and  the  response  time  from  the  OEM. 
The  progression  through  this  process  was  monitored  through  the  use  of  a  status  matrix 
described  in  Enclosure  (23)  -  Vendor  Status  Report.  This  status  matrix  was  updated  on  a 
weekly  basis  and  reported  to  the  program  support  IPT  as  requested. 

c)  SEDI  Context:  Enclosure  (15)  SSDS  MK  1&2  Prioritized,  COTS 
List,  Early  Maturity 

The  activity  in  defining  the  priority  for  each  item  is  a  teaming  function 
where  all  members  must  actively  participate  to  yield  an  adequate  product.  The 
dependence  of  hardware  to  software  is  of  key  concern  in  assigning  the  priority  levels.  In 
some  circumstances,  some  assemblies  will  be  inherently  linked  to  other  assemblies  such 
that  a  change  to  one  impacts  the  other  and  therefore  need  to  be  grouped  as  like  priority  in 
the  overall  scheme  of  the  list.  Enclosure  (15)  provides  the  combined  SSDS  MK  1&2 
prioritized,  COTS  list,  in  a  state  of  maturity  about  half  way  through  the  process.  During 
the  development  of  this  workbook  there  were  several  spreadsheets  that  were  used  to 
develop  the  all-up  list  described  in  worksheet  4.  This  worksheet  illustrates  the  identified 
COTS  OEMs,  the  configurations  of  interest,  the  points  of  contact  at  the  OEM,  the  amount 
of  assemblies  needed  for  the  next  10  years  at  a  50%  and  99%  confidence  levels,  and 
implementation  notes;  all  arranged  in  prioritized  order.  This  worksheet  was  used 
extensively  to  communicate  the  what,  who,  how,  and  when  regarding  the  SSB  system 
implementation  activities.  Enclosure  (16)  presents  the  same  workbook  at  a  much  later 
time,  a  review  of  spreadsheet  4  shows  how  this  communication  tool  has  been  modified  to 
give  an  update  of  the  implementation  process  and  identify  actions  and  recommendations 
to  the  budgeting  planning  activities.  Using  these  tools  helps  organize  your  efforts  and 
aids  in  communication  with  the  rest  of  the  team. 

The  information  regarding  each  company  and  all  the  configurations  under 
consideration  is  extensive  and  will  get  confusing  unless  it  is  organized  in  a  methodical 
way  and  the  records  are  updated  regularly  and  consistently.  The  example  provided  in 
Enclosure  (15)  -  SSDS  MK  1&2  prioritized,  COTS  list,  illustrates  the  method  that  was 
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used  during  the  implementation  process  for  the  SSDS  programs.  Key  information 
provided  in  this  matrix  is  typically  needed  during  almost  every  contact  with  the  potential 
candidates.  The  matrix  also  has  columns  to  annotate  information  already  gathered  and 
actions  yet  to  be  taken.  In  essence  the  matrix  is  used  much  like  a  sales  persons  contact 
list  in  providing  important  information  that  is  continuously  updated  to  reflect  the  ongoing 
communication  with  the  customer. 

Output  Products 

d)  SEDI  Context:  Enclosure  (24)  Obsolescence  Health  Report 

On  an  annual  basis  or  as  requested  by  the  PMO,  the  detailed  infonnation 
on  all  assemblies  in  the  SSB  system  pertaining  to  a  specific  program  are  assembled  into  a 
single  document  and  provided  to  that  program  as  a  SSB  system  update.  Enclosure  (24)  - 
Obsolescence  Health  Report  is  the  SSDS  example  of  such  a  report.  These  reports  are 
extensive  since  the  following  infonnation  is  provided:  the  status  of  the  SSB  system 
implementation,  the  assemblies  obsolescence  health  arranged  per  system  indenture,  a 
summary  report  of  obsolete  component  piece  parts  (Red,  high  risk  values),  graphical 
depiction  of  the  obsolescence  health  analysis,  and  executive  summary  for  the  system. 
The  format  and  detail  is  dependent  on  the  request  or  needs  of  the  specific  program,  so 
before  arbitrarily  adopting  the  example  format  we  suggest  interfacing  with  your  program 
before  proceeding. 

The  following  files  are  used  to  construct  the  Obsolescence  Health  Report 
and  once  assembled  provide  a  complete  obsolescence  risk  picture: 

•  SSDS  Obsolescence  Report,  main  body  w/o  Graphics 

•  Vendor  Status 

•  Cover  Pages  for  Appendices  A,  B,  C,  D 

•  Appendix  A:  MK1  Configuration  List 

•  Appendix  B:  MK2  Configuration  List 

•  Appendix  C:  MK1  Obsolescence  Health,  Graphical 

•  Appendix  D:  MK2  Obsolescence  Health,  Graphical 

•  Appendix  E:  SSB  Implementation 
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e)  SEDI  Context:  Enclosure  (25)  SSDS  Red  Component  List 

One  of  the  products  of  the  preceding  step  is  a  list  of  red  coded  piece  parts 
identifying  them  a  high  obsolescence  risk  items.  Enclosure  (25)  -  SSDS  Red  Component 
List  provides  an  example  of  such  a  list.  These  specific  parts  have  been  discontinued  and 
soon  will  not  be  available  for  purchase. 

f)  SEDI  Context:  Enclosure  (27)  Obsolescence  Impact  &  Purchase 
Request  Report 

The  purchase  of  Grey  Market  parts  will  continue  to  be  an  ongoing 
function  as  new  high-risk  parts  are  identified.  Depending  on  the  impact  both  risk  and 
financial,  the  purchase  of  obsolete  parts  may  be  as  simple  as  an  email  form  (see 
Enclosure  (26))  or  as  fonnal  as  a  detailed  report.  Enclosure  (27)  -  Analysis  of  Intel’s 
i680  obsolescence  on  OEM  products  -  SSDS  program  -  is  a  good  example  of  how  to 
structure  a  detailed  impact  and  purchase  request  due  to  obsolescence.  It  will  be  important 
to  automate  this  process  as  much  as  possible  because  there  will  be  a  continuous  stream  of 
these  requests  over  the  years  the  programs  system  need  to  be  supported. 

g)  SEDI  Context:  Enclosure  (28)  SSDS  Assembly  Master  &  Cost 
Matrices 

The  last  area  of  measurement  and  assessments  is  the  “Capstone”  of  the 
entire  SSB  system’s  implementation  effort.  It  brings  together  all  the  infonnation  and  data 
collected  and  provides  functionality  previously  unattainable  without  the  SSB  system  - 
Systems  Engineering  approach.  The  “Capstone”  assessment  tool  is  illustrated  in 
Enclosure  (28)  -  SSDS  Assembly  Master  &  Cost  Matrices.  Every  tool,  method,  and 
process  developed  to  implement  the  SSB  system  is  either  directly  or  indirectly 
responsible  for  the  numbers  evident  in  the  matrices.  Enclosure  (29)  -  SSB  Planning 
Excel  Workbook  &  Data  Item  Description  -  provides  detailed  explanations  for  the 
descriptions  of  each  cell  along  with  the  mathematical  relationships  and  constraints 
implemented  within  the  worksheet. 
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IV.  DATA  ANALYSIS 


A.  INTRODUCTION 

In  this  section  the  potential  financial  and  non-financial  consequences  will  be 
presented  along  with  specific  areas  of  benefit  to  the  business  process.  An  analysis  of  the 
cost  data  has  been  presented  in  the  form  of  data  summaries  in  Appendix  C  (The  Business 
Case  Analysis)  for  the  SSDS  MKI  only.  The  SSDS  MKI  program  supplied  the  most 
compete  package  of  reliable  financial  data  among  the  systems  currently  implementing  the 
SSB  system.  In  terms  of  non-financial,  this  document  draws  from  all  three  programs 
(SSDS  MI,  SSDS  MKII  &  AN/ASQ-20X).  The  data  in  this  section  is  offered  in  an 
objective  and  broad  manner.  Where  details  are  needed,  guidance  to  specific  appendices  is 
given.  The  financial  data  and  their  contribution  to  the  SSB  implementation  are  fairly 
straightforward.  Two  separate  model  are  used  to  estimate  the  costs  to  the  program:  The 
Resource  Model  and  The  Procurement  Model.  The  resource  modeling  is  accomplished 
using  the  NSWC  Crane  cost  model,  which  takes  into  account  all  the  various  aspects  of 
implementing  an  Engineering  Change  Proposal  (ECP).  This  model  covers  over  128 
functions/activities  and  is  tailored  to  meet  the  needs  of  the  application  under 
consideration.  The  Procurement  Model  is  provided  in  Enclosure  (28)  of  the  SEDI  Plan 
and  provides  the  ability  to  simulate  various  scenarios  with  “what  if’  procurement  trade¬ 
offs  to  identify  Navy  “best  value”.  The  most  optimal  values  resulting  from  the 
Procurement  Model  are  fed  into  the  Resource  Model  to  estimate  the  total  support  costs  to 
the  program.  Between  these  two  models  and  a  few  other  tools  used  in  the  SSB  system, 
the  program  can  get  the  “Big  Picture”  view  of  the  supportability  requirements  for  their 
program.  Cost  data  is  analyzed  for  various  support  scenarios  under  the  SSDS  MKI  and 
alignment  to  specific  goals  is  made.  We  make  the  obvious  assumption  that  cost  data  and 
the  results  derived  from  analysis  would  be  consistent  across  the  other  programs.  Non- 
financial  impacts  are  derived  from  both  the  Business  Case  Analysis  as  well  as  the 
Marketing  Plan.  As  mentioned  previously,  the  Marketing  Plan  includes  the  analysis  of 
several  environmental  elements  and  effectively  defines  the  strength  and  weakness  of  the 
SSB  as  well  as  potential  opportunities  or  threats. 
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B.  ANALYSIS  OF  RESULTS 


In  this  section  we  derive  usable,  decision  quality  infonnation  from  the  results 
detailed  in  each  of  the  four  appendices.  The  results  will  be  summarized  and  evaluated  for 
their  contribution  to  the  business  objectives.  This  section  will  address  both  financial 
metrics  as  well  as  non-financial  implications. 

1.  Direct  Financial  Impacts 

The  direct  financial  impacts  were  derived  from  SSB  implementation  on  the  SSDS 
MKI  program.  The  initial  SSB  implementation  efforts  were  focused  on  the  SSDS  MKI 
program  and  therefore  offered  the  most  complete  set  of  data.  A  logical  assumption  is 
made  that  extends  these  impacts  to  other  programs.  Detailed  analysis  is  provided  in 
Appendix  C  (The  Business  Case  Analysis).  First  we  will  focus  on  the  direct  financial 
impacts  which  are  discussed  with  some  brief  background  infonnation.  To  understand  the 
full  impact  of  SSB  implementation  several  scenarios  were  considered.  There  are  three 
primary  scenarios  that  are  viewed  as  the  most  practical  given  the  current  state  of  the 
SSDS  MKI  program.  These  three  scenarios  are  considered  the  most  feasible  course  of 
actions  over  the  defined  ten-year  support  period: 

1)  LTB  (1)  -  This  scenario  is  the  likely  track  for  COTS  product  support  without 
any  assistance  from  the  SSB  infrastructure.  The  costs  for  this  scenario  are  the 
estimated  financial  impacts  that  the  SSDS  Program  Office  must  plan  for.  The 
support  methods  are  broken  down  into  two  methods:  1)  Life  of  Type  Buy 
(LTB),  which  is  a  bridge  buy  as  described  previously,  and  2)  OTHER.  OTHER 
refers  to  redesign,  spares  utilization,  reclamation  from  other  Fleet  assets  or 
maintenance  contracts. 

2)  SSB  (1)  -  This  scenario  is  the  most  appropriate  implementation  of  the  SSB 
infrastructure  as  agreed  upon  by  the  SSDS  COTS  Working  Group  (SCWG). 
Three  main  support  methods  are  employed:  1)  SSB,  2)  LTB  and  3)  OTHER  as 
described  above. 

3)  SSB  Optimized  -  This  scenario  implements  the  SSB  method  wherever  possible. 
Certain  support  decisions  were  made  for  specific  COTS  products  prior  to  the 
availability  of  the  SSB  infrastructure.  Some  COTS  products  have  already  been 
slated  for  redesign  or  reclamation  efforts. 

In  addition  to  these  scenarios,  three  additional  scenarios  are  identified.  These 
represent  the  “What-If  ’  scenarios. 

1)  LTB  Only  -  This  scenario  uses  the  LTB  support  method  for  all  COTS  products. 
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2)  SSB  Only  -  This  scenario  uses  the  SSB  support  method  for  all  COTS  products. 

3)  Complete  Tech  Refresh  -  In  this  scenario  every  COTS  product  within  the 
SSDS  is  planned  for  redesign  or  technology  refresh  over  the  next  ten-year 
period.  The  refresh  is  planned  and  scheduled  based  on  “End  of  Production” 
(EOP)  dates  provided  from  the  Original  Equipment  Manufacturers  (OEM). 


The  financial  aspects  are  summarized  below  for  the  six  scenarios. 


Scenario 

First  Year 
Costs 

Total 

All  Years 

NPV  Total 
All  Years 

Consumed 

Inventory 

NPV 

Adjusted 

Total 

Complete 

Tech 

Refresh 

$2,316 

$71,342 

$61,089 

$0 

$61,089 

LTB(l) 

$5,924 

$9,639 

$8,651 

$701 

$9,352 

SSB(l) 

$3,440 

$8,415 

$7,333 

$701 

$8,034 

SSB 

Optimized 

$2,858 

$8,665 

$7,321 

$701 

$8,022 

LTB  Only 

$5,234 

$8,970 

$7,981 

$0 

$7,981 

SSB  Only 

$1,727 

$9,170 

$7,539 

$0 

$7,539 

Table  1:  Total  Support  Costs  Scenarios  ($K) 


The  above  table  demonstrates  the  potential  savings  in  the  first  year  as  well  as  the 
overall  costs  to  support  the  SSDS  program  over  the  defined  ten-year  period. 

1)  When  the  SSB  process  was  implemented,  regardless  of  degree,  significant 
savings  were  realized.  See  column  NPV  Adjusted  Total  in  the  above  table. 

2)  When  the  SSB  process  was  implemented,  the  initial  year  costs  were  reduced 
indirectly  proportional  to  the  degree  of  SSB  implementation.  See  column  First 
Year  Costs  in  the  above  table. 

From  the  above  table,  a  Complete  Technology  Refresh  is  the  most  cost 
prohibitive  course  of  action,  given  a  stabilized  requirements  baseline.  With  that  said,  the 
following  table  provides  the  procurement  costs  for  each  scenario,  excluding  a  Complete 
Tech  Refresh  given  the  cost  and  complexity  of  estimating  such  an  effort.  Additionally, 
an  adjustment  has  been  made  to  the  scenarios  below  as  compared  to  the  previous  Table  1. 
Common  to  all  scenarios  in  Table  2  -  Procurement  Costs  -  is  the  cost  to  refresh  9  items 
which  regardless  of  which  method  chosen  to  provide  long-term  support,  these  refresh 
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costs  must  be  paid.  The  9  items  for  refresh  were  removed  to  present  only  the  portion  of 
each  scenario  impacted  by  the  long-term  support  decision-making  process.  The  removal 
of  the  cost  of  the  9  refresh  items  explains  the  cost  deferential  between  the  two  tables  1  & 


2.  For  details  concerning  this  adjustment  see  Appendix  C:  Business  Case  Analysis. 


Scenario 

First  Year 
Costs 

Total 

All  Years 

NPV  Total 
All  Years 

Consumed 

Inventory 

NPV 

Adjusted 

Total 

LTB(l) 

$5,924 

$7,069 

$6,871 

$701 

$7,571 

SSB(l) 

$3,059 

$6,854 

$6,025 

$701 

$6,726 

SSB 

Optimized 

$2,477 

$7,004 

$6,012 

$701 

$6,712 

LTB  Only 

$5,234 

$6,400 

$6,201 

$0 

$6,201 

SSB  Only 

$1,346 

$7,609 

$6,231 

$0 

$6,231 

Table  2:  Procurement  Costs  ($K) 


The  above  table  demonstrates  the  potential  procurement  savings  in  the  first  year 
as  well  as  the  overall  costs  to  support  the  SSDS  program  over  the  defined  ten-year  period. 

1)  When  the  SSB  process  was  implemented,  regardless  of  degree,  significant 
savings  were  realized.  See  column  NPV  Adjusted  Total  in  the  above  table.  The 
figure  for  SSB  Only  is  slightly  larger  than  for  LTB  Only.  The  reason  for  this  is 
because  the  SSB  process  requires  a  cost  to  purchase  Red  Parts  each  year,  the 
first  year  being  $534,01 1  and  a  total  for  all  years  of  $828,426.  The  LTB 
methods  make  the  assumption  that  they  can  purchase  all  the  required  items 
upfront  for  usage  throughout  the  ten-year  period  and  that  all  item  will  be 
consumed.  There  is  risk  involved  with  buying  too  many  or  not  enough  items  in 
both  the  LTB  and  SSB  cases.  However,  the  substantial  difference  between  the 
two  alternatives  is  the  investment  risk  of  the  total  assembly  (the  LTB  case)  at 
say  $6500.00  versus  the  investment  in  component  parts  (the  SSB  case)  at  a 
mere  $40.00  then  buying  the  total  assembly  later  when  the  Navy  needs  it. 

2)  When  the  SSB  process  was  implemented,  the  initial  year  costs  were  reduced 
indirectly  proportional  to  the  degree  of  SSB  implementation.  See  column  First 
Year  Costs  in  the  above  table. 

When  we  perform  standard  deviation  calculations  over  the  ten-year  period  we  get 
the  following. 


64 


STD  DEV 

LTB(l) 

LTB  Only 

SSB(l) 

SSB 

Optimized 

SSB  Only 

2003-2012 

All  Years 

1836 

1617 

836 

627 

231 

2004-2012 
Excludes  Initial 
Year 

100 

102 

55 

61 

111 

2004-2011 
Middle  years 

105 

108 

10 

7 

16 

Table  3:  Procurement  Costs  STD  DEV  Year-Year  ($K) 


1)  When  the  SSB  process  is  implemented,  we  experience  a  more  stabilized 

funding  profile  for  procurement,  particularly  for  the  middle  eight  years.  See  the 
above  table. 

When  we  look  at  total  support  costs  for  each  scenario  we  get  the  following  STD 
DEV  Year-Year  Total  Costs.  Remember,  for  the  LTB(l)  and  SSB(l)  scenarios  we  had  to 
take  into  account  a  redesign  effort  for  nine  COTS  items.  This  cost  is  incurred  early  in  the 


ten-year  period  and  affects  the  overall  stability  of  the  funding  profile. 


STD  DEV 

LTB(l) 

LTB  Only 

SSB(l) 

SSB 

Optimized 

SSB  Only 

2003-2012 

All  Years 

1896 

1597 

1322 

1208 

303 

2004-2012 
Excludes  Initial 
Year 

1068 

508 

1135 

1131 

111 

2004-2011 
Middle  years 

1056 

526 

1188 

1186 

16 

Table  4:  Total  Support  Costs  STD  DEV  Year-Year 


1)  When  SSB  is  implemented  early  enough  we  can  effectively  avoid  any  redesign 
costs  that  would  be  needed  due  to  obsolescence  during  the  ten-year  period  and 
therefore  expect  the  greatest  stability  in  the  funding  profile  over  the  ten-year 
period. 

The  percentage  of  overall  initial  costs  associated  with  each  scenario  is  given 

below. 
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Figure  7:  Total  Initial  Support  Cost 

1)  When  the  SSB  process  was  implemented,  the  initial  cost  as  a  percentage  of  the 
total  cost  to  the  program  was  significantly  reduced  depending  on  the  degree  of 
implementation.  This  helps  to  reduce  the  risks  associated  with  making  large 
upfront  investments  because  the  costs  are  more  evenly  distributed  over  the 
entire  ten  years. 

2)  When  the  SSB  process  was  implemented,  the  costs  are  more  evenly  distributed 
over  the  ten-year  period  depending  on  the  degree  of  implementation.  This  is 
more  desirable  for  planning  and  budgetary  purposes. 

The  following  table  provides  the  costs  associated  with  having  to  redesign  those 
COTS  products  that  were  targeted  for  redesign  prior  to  SSB  implementation.  These 
items  were  determined  to  become  obsolete  prior  to  the  end  of  the  support  scenario,  and 
unsupportable  via  traditional  support  mechanisms  or  with  the  SSB  system. 


WBS  Element 

Total  ($K) 

Total 

7063 

Configuration  Management 

126 

Hardware/Software  Engineering 

1684 

Testing  And  Documentation 

944 

Procurement 

3866 

ILS  Planning  and  Management 

337 

Installation 

107 

Table  5:  Re-design  Cost  Avoidance,  9  Items 
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1)  The  total  cost  that  could  have  been  potentially  avoided  if  the  SSB  process  had 
been  implemented  for  those  identified  COTS  products  is  approximately 
$7.063M. 

This  $7.063M  cost  is  considered  the  potential  Avoided  Costs  when  implementing 
the  SSB  process  if  applied  immediately  after  the  SSDS  design  was  baselined  and  before 
irreversible  obsolescence  takes  place.  The  optimal  time  to  implement  the  SSB  system  is 
the  earliest  point  in  the  systems  design  process  where  a  stabilized  baseline  can  be 
identified. 

The  following  summaries  show  the  savings  in  $K  for  procurement,  resources  and 


the  total  support  costs  between  the  two  most  practical  scenarios  (LTB(l)  and  SSB(l). 


LTB(l)  Procurement  Cost  (Typical  scenario) 

SSB(l)  Procurement  Cost  (Actual  SSB  Implementation) 

$6871 

$6025 

Procurement  Savings  ($K) 

$846 

LTB(l)  Resource  Cost 

$1780 

SSB(l)  Resource  Cost 

$1308 

Cost  Savings  ($K) 

$  472 

LTB(l)  Total  Support  Cost 

$8651 

SSB(l)  Total  Support  Cost 

$7333 

Cost  Savings  ($K) 

$1318 

Table  6:  Cost  Savings  SSB(l)  versus  LTB(l)  ($K) 


1)  When  the  SSB  process  was  implemented  significant  cost  savings  is  realized. 

The  following  data  illustrates  the  potential  savings  of  the  current  typical  support 
scenario  of  LTB  and  a  required  tech  refresh  of  nine  items  and  SSB  for  all  COTS  products 


upfront. 


LTB(l) 

SSB  Only 

$8651 

$7539 

Potential  Cost  Savings  ($K) 

$1112 

Cost  Tech  Refresh  of  9  Items 

$7063 

Cost  to  SSB  the  9  Items 

$669 

Avoided  Cost  Savings  ($K) 

$6394 

Total  Potential  Cost  +  Avoided  Savings 

$7506 

Table  7:  Total  Cost  “Savings  &  Avoidance”  Using  the  SSB  ($K) 


1)  If  SSB  was  implemented  for  all  COTS  products  early  enough  we  can  essentially 
avoid  the  cost  associated  with  a  required  partial  tech  refresh. 
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The  final  summary  of  data  looks  at  the  extreme  cases.  The  following  illustrates 

the  total  support  cost  savings  between  implementing  SSB  early  in  the  acquisition  cycle  to 

affect  all  COTS  products  and  redesigning  all  COTS  products. 

Complete  Tech  Refresh  $61089 

SSB  Only  $  7539 

Procurement  Savings  ($K) $53550 

Table  8:  Cost  Savings:  SSB  only  Versus  Complete  Tech  Refresh  ($K) 


In  looking  at  the  SSB  portion  of  the  first  year  procurement  costs  for  each  scenario 
we  get  the  following  table. 


Support  Method 

Non  SSB  Costs 

SSB  Costs 

SSB%  of  Total 
Costs 

LTB(l) 

$5,924 

$  0 

0.0% 

LTB  Only 

$5,234 

$  0 

0.0% 

SSB(l) 

$2,097 

$  962 

31.4% 

SSB  Optimized 

$1,321 

$1,156 

46.7% 

SSB  Only 

$  103 

$1,243 

92.3% 

Table  9:  Initial  (First  Year)  Procurement  Costs  Comparison:  SSB  Versus  LTB 


1)  For  all  but  the  'SSB'  Only  (scenario  four),  the  majority  of  the  initial 
procurement  costs  are  associated  with  non-SSB  support  mechanisms. 

2)  The  greater  degree  of  SSB  implementation  the  lower  the  initial  investment  and 
thus  lower  program  risk. 

In  comparing  the  resource  models  for  the  traditional  LTB  methods  and  expected 
SSB  implementations  we  notice  similar  orders  of  magnitude  for  total  costs. 
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WBS  Element 

Actual  ($K) 

Traditional  ($K) 

Total 

8415 

9639 

Configuration  Management 

0 

57 

Hardware/Software  Engineering 

0 

0 

Testing  and  Documentation 

0 

0 

Procurement 

10 

7069 

ILS  Planning  and  Management 

0 

2354 

Installation 

158 

Sunset  Supply  Costs 

8404 

- 

Table  10:  Comparison  of  Total  Resource  Costs:  SSB  &  LTB 


The  SSB  infrastructure  absorbs  nearly  all  the  costs  for  supporting  COTS  products 
over  the  ten-year  period. 

1)  The  expected  scenario  provides  infrastructure  to  support  the  SSDS  program, 
resulting  in  greater  flexibility  and  manageability  for  the  program  manager. 

2)  Implementation  of  the  SSB  infrastructure  is  possible  at  the  same  or  lower  cost 
to  the  program  as  traditional  LTB  methods. 

2.  Non-Financial  Impacts 

Certain  non-financial  impacts  materialize  based  in  part  on  financial  consequences. 
In  order  to  successfully  evaluate  the  results  of  implementing  the  SSB  process  we  must 
look  at  these  non-financial  aspects  in  light  of  the  business  objectives.  But  first  we  must 
clearly  derive  such  impacts.  Since  no  clear  financial  metric  can  be  applied  to  these 
impacts  we  will  discuss  them  in  broad  terms  and  in  ways  that  can  be  observed  and 
verified.  The  approach  here  will  declare  a  financial  outcome  or  business  practice  of 
implementing  the  SSB  infrastructure,  and  explain  in  non-financial  terms  the  tangible 
impact. 


a)  Low  Initial  Expense 

By  reducing  the  upfront  costs  for  procuring  expected  spares,  the  SSB 
process  brings  improved  flexibility  to  planning  and  budgeting.  If  the  initial  costs  are 
large  then  the  PMO  is  forced  to  stay  the  course  for  the  entire  period  in  order  to  derive  the 
maximum  return  on  investment.  Changing  program  direction  during  the  ten-year  period 
would  be  difficult  to  argue  given  the  number  of  spare  COTS  products  that  would  become 
potentially  useless.  Under  the  SSB  infrastructure  much  of  the  initial  costs  are  still 
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associated  with  non-SSB  support  mechanisms;  therefore,  these  costs  will  be  absorbed  in 
the  event  the  program  did  not  make  use  of  the  assets  that  were  procured.  In  the  All  SSB 
scenario,  nearly  all,  about  92%,  of  the  upfront  costs  are  for  SSB  support.  The  benefits 
associated  with  this  cost  are  immediately  realized,  that  is  the  procured  COTS  items  are 
deployed  to  the  Fleet  for  use  upon  purchase.  Furthennore,  in  the  event  that  performance 
requirements  change,  driving  a  change  in  system  design,  the  risks  are  greatly  reduced 
since  less  of  an  investment  was  made  for  spares  that  may  not  be  needed.  So  therefore  the 
SSB  process  effectively  reduces  the  risk  of  overspending  early  in  the  support  cycle. 

Derived  Benefits: 

•  Cost  Savings 

•  Flexibility 

•  Reduced  risk 

•  Stability 

b)  Stable  Funding  Profile 

The  SSB  process  spreads  the  procurement  costs  more  evenly  throughout 
the  ten-year  period.  This  makes  efficient  use  of  funds  and  is  easier  to  budget  and 
manage.  The  yearly  costs  are  higher  under  the  SSB,  but  that’s  because  no  investment  in 
spares  was  made  the  first  year.  Nevertheless,  as  before,  the  costs  associated  with  these 
years  are  for  forecasted  replacements  on  an  as  need  basis.  The  costs  are  incurred  at  the 
moment  a  requisition  is  made  for  a  replacement  COTS  item.  The  benefit  is  immediately 
realized.  Furthermore,  by  procuring  COTS  replacement  products  only  on  demand  the 
program  manager  makes  better  use  of  funds.  Also,  continual  market  surveillance  is 
practiced  throughout  the  support  cycle  providing  real-time  data  in  terms  of  obsolescence 
and  diminishing  materials.  In  this  way  the  program  manager  is  better  equipped  to  make 
effective  decisions  that  benefit  the  overall  program.  This  environment  creates  a  flexible 
process  that  by  taking  a  proactive  posture  can  react  to  changes  in  material  availability. 

Derived  Benefits: 

•  Stability 

•  Efficient  use  of  funds 
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•  Flexibility 

•  Risk  Mitigation  &  Management 

c)  The  Sunset  Supplier  Shares  Risk 

One  area  of  cost  savings  not  addressed  was  the  cost  to  the  Navy  for 
stockage,  storage  and  issue  of  COTS  spares  and  repair  parts.  These  are  costs  not  directly 
borne  by  the  SSDS  program.  But  in  addition  to  the  cost  savings  to  the  Navy  for  not 
having  to  house,  manage  and  transport  these  COTS  items,  the  Sunset  Supplier  now 
assumes  the  responsibility,  and  thus  risk,  of  facilitating  these  functions  and  recoup  the 
value  added  by  adjusting  the  product  purchase  price  by  5%  on  each  COTS  item  procured. 

Derived  Benefits: 

•  Risk  Mitigation  &  Management 

•  Shared  Risk 

•  Shared  responsibility 

•  Collaborative  Environment 

d)  Extending  COTS  Supportability 

By  implementing  the  SSB  process  early  enough  in  the  program,  we  can 
effectively  extend  supportability  for  these  items.  And  in  fact  we  can  extend  the 
reparability  of  these  items  by  identifying  and  procuring  near-obsolete  components  (Red 
Parts).  In  this  particular  case  (SSDS  MK  1),  by  the  time  the  SSB  infrastructure  was  in 
place,  it  was  too  late  to  mitigate  the  re-design  cost  on  9  items  and  the  subsequent  cost  the 
program  was  an  additional  7  million  dollars.  The  planning  for  redesign  carries  certain 
risks  as  well.  DoD  will  almost  certainly  use  COTS  products  for  the  commercial 
technology  advantages,  touched  on  earlier  in  this  document,  applying  the  technology  to 
work  towards  specific  warfighter  performance  requirements.  For  the  COTS  products 
identified  on  the  SSDS  MK  1  program,  the  items  were  determined  to  be  obsolete  by 
2005-6  timeframe.  Now  remember  that  there  is  a  2-3  year  planning  period  and  additional 
5-7  year  implementation  period  for  new  designs.  If  the  period  of  concern  starts  in  2003, 
the  COTS  products  will  become  completely  unsupportable  before  the  planning  phase 
even  ends.  By  implementing  the  SSB  process  we  effectively  avoid  this  situation  by 
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extending  supportability  of  the  COTS  products  so  that  warfighter  requirements  can 
continue  to  be  met  while  plans  are  made  to  upgrade  the  system.  By  stabilizing  the  system 
baseline  in  this  way  we  mitigate  the  risks  of  not  being  able  to  support  the  warfighter  to 
acceptable  levels. 

Derived  Benefits: 

•  Extending  COTS  Supportability 

•  Extend  COTS  Reparability 

•  Cost  Savings/Cost  Avoidance 

•  Stabilize  System  Baseline 

•  Risk  Mitigation  &  Management 

e)  Initial  Investment 

The  initial  cost  for  setting  up  the  SSB  infrastructure  and  making  the  initial 
COTS  product  assessments  was  approximately  $380K  (see  Appendix  C).  This  is  a 
minor  investment  considering  that  the  realizable  return  is  substantial  depending  on  how 
early  in  the  acquisition  cycle  SSB  is  implemented.  For  example,  the  cost  of  support  for 
the  present  SSDS  before  SSB  was  considered  was  estimated  to  be  $865  IK  plus  an 
additional  partial  tech  refresh  cost  of  $6394K  (total  of  $15045K).  The  estimated  cost  of 
implementing  SSB  early  enough  to  affect  all  COTS  products  was  $7539K.  The  potential 
savings  is  roughly  $7.5M.  That  in  itself,  is  a  wonderful  marketing  element,  however 
there  is  also  another  point  to  be  made;  and  that  is  that  this  setup  and  assessment  can  be 
performed  for  any  program.  Thus,  the  SSB  process  is  transportable  and  repeatable.  And 
as  the  proliferation  of  COTS  products  increases  throughout  the  military,  there  is  a  strong 
likelihood  that  commonality  of  COTS  products  across  weapon  systems  will  grow.  Having 
a  SSB  process  that  maintains  and  continually  updates  a  database  of  these  COTS  products 
for  usage,  obsolescence,  and  diminishing  materials  will  provide  a  tremendous  benefit 
whose  value  will  grow  exponentially.  Thus,  the  SSB  process  is  also  expandable.  This 
initial  investment  is  made  within  the  DoD,  tasking  Navy  resources  to  perform 
supportability  assessments  and  DMSMS/Obsolescence  Management.  The  reports 
generated  become  government  property  and  distributed  among  the  DoD  Program  Offices 
as  well  as  commercial  support  entities  (Sunset  Supplier,  OEMs,  system  integrators,  etc.). 
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Therefore  other  programs  can  leverage  the  data  and  the  relationships  from  the  SSB 
infrastructure.  This  initial  investment  is  also  used  to  fund  the  government  facilitating 
activity  for  pursuing  and  coordinating  potential  OEM  and  Sunset  Suppliers,  a  reusable 
collaborative  resource. 

Derived  Benefits: 

•  Transportable,  repeatable  and  expandable. 

•  DMSMS/Obsolescence  reporting 

•  Collaborative  Environment 


•  Coordination 


I  Summary  of  Benefits  | 

Financial 

Non-Financial 

•  Reduced  Procurement  Cost 

•  Lower  Upfront  Costs 

•  Significant  Cost  Avoidance 

•  Stabilized  Funding  Profile 

•  Overall  Cost  Savings  to  the  Program 

•  Flexibility  -  Planning  &  Budgeting 

•  Reduced  risk 

•  Stability  -Funding  Profile 

•  Efficient  use  of  funds 

•  Risk  Mitigation  &  Management 

•  Shared  Risk 

•  Shared  Responsibility 

•  Collaborative  Environment 

•  Extending  COTS  Supportability 

•  Extend  COTS  Reparability 

•  Stabilize  System  Baseline 

•  Transportable,  repeatable  and 
expandable. 

•  DMSMS/Obsolescence  reporting 

•  Coordination 

Table  11:  Summary  of  SSB  Financial  and  Non-Financial  Benefits 


SSB  Specific  Goal 

Derived  Benefit 

Achieve  significant  and  quantifiable  cost 
savings  over  the  product  life  cycle. 

•  Reduced  Procurement  Cost 

•  Lower  Upfront  Costs 

•  Significant  Cost  Avoidance 

•  Stabilized  Funding  Profile 

•  Overall  Life  Cycle  Cost  Savings  to  the 
Program 

To  be  able  to  identify,  quantify,  and 
mitigate  supportability  risk  to  programs. 

•  DMSMS/Obsolescence  reporting 

•  Reduced  risk 

•  Risk  Mitigation  &  Management 
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SSB  Specific  Goal 

Derived  Benefit 

•  Shared  Risk 

Extend  the  life  cycle  and  supportability  of 
COTS. 

•  Extending  COTS  Supportability 

•  Extending  COTS  Reparability 

Provide  infrastructure  to  support  existing 
platform/combat  systems  in  support  of  the 
Program  Office. 

•  Transportable,  repeatable  and 
expandable. 

•  Coordination 

•  Collaborative  Environment 

•  Infrastructure  support  for  existing 
weapon  systems 

A  reliable,  affordable,  repeatable,  and 
expandable  process  that  meets  the 
customer’s  performance  expectations  (e.g., 
accessible,  transportable,  maintainable, 
predictable). 

•  DMSMS/Obsolescence  reporting 

•  Transportable,  repeatable  and 
expandable. 

•  Stabilize  System  Baseline 

Institutionalize  methods  for  proactive 
management  of  COTS  including  DMSMS 
issues. 

•  DMSMS/Obsolescence  reporting 

•  Collaborative  Environment 

A  system  that  leverages  Navy  and 
commercial  supportability  assets  and 
provides  a  networked  solution. 

•  Collaborative  Environment 

•  Shared  Responsibility 

•  Shared  Risk 

•  Coordination 

Leverage  across  government  programs  with 
extended  applicability  through  contract 
strategies,  methodologies,  and  incentives  to 
entice  commercial  industry  participation. 

•  Flexibility  -  Planning  &  Budgeting 

•  Transportable,  repeatable  and 
expandable 

•  Collaborative  Environment 

Forecast  budget  requirements  in  support  of 
the  programs/war  fighter/consumer 

•  Flexibility  -  Planning  &  Budgeting 

•  Efficient  use  of  funds 

•  DMSMS/Obsolescence  reporting 

Improve  schedule  flexibility  and  support 
options  of  system  upgrades  or  new 
development  initiatives. 

•  Flexibility  -  Planning  &  Budgeting 

•  Extending  COTS  Supportability 

•  Stabilize  System  Baseline 

Table  12:  Alignment  with  SSB  Specific  Goals  to  Derived  Benefits 
C.  INTERPRETATION  OF  RESULTS 


From  the  above  analysis  we  can  make  several  convincing  recommendations  for 
SSB  acceptance;  however,  we  must  also  understand  the  environmental  forces  that 
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constrains  SSB  implementation  in  order  to  develop  a  clear  picture  of  SSB  viability  and 
value.  Appendix  D  (The  SSB  Marketing  Plan)  provides  a  detailed  analysis  of  customer, 
competitor  and  SSB  system  elements.  The  outcome  of  which  provides  resource 
requirements,  such  as  people,  implementation  control  requirements,  which  provide 
criterion  measures  for  SSB  implementation  success,  and  finally,  likely  evolutionary 
changes  for  future  SSB  implementations.  Together  the  above  tabulated  results  and  the 
Marketing  Plan,  the  following  results  are  provided  in  terms  of  strength,  weaknesses, 
opportunities  and  threats: 

1.  Strengths 

Strength  1:  The  SSB  system  provides  an  expandable,  transportable,  Life 

Cycle  Cost  (LCC)  reducing  processes,  methods,  and  tools. 

The  expandable  characteristic  of  the  SSB  system  allows  it  to  be  applicable  to 
most  any  program  regardless  of  size.  This  scalability  ensures  that  the  SSB  system  will  be 
able  to  keep  pace  with  a  programs  growth  and  the  addition  of  other  COTS  products  as  the 
programs  system  is  modernized.  The  transportability  feature  addresses  the  issue  of  long¬ 
term  support  of  the  SSB  system  itself  so  if  it  was  no  longer  viable  to  receive  services 
from  the  current  Organic  activity  providing  the  service  then  at  the  programs  option  the 
support  function  could  be  moved  to  another  activity.  Simply  stated  this  feature  assures 
the  longevity  of  the  SSB  systems  support.  The  LCC  reductions  possible  due  to  the 
implementation  of  the  SSB  system  is  the  strongest  driver  for  the  SSB  system  acceptance. 
These  reductions  are  one  of  the  most  unique  characteristics  of  the  SSB  system  and  a  clear 
differentiating  attribute  which  impacts  one  of  the  most  prominent  metrics  the  PMO’s 
success  is  judged  against,  Life  Cycle  Cost.  The  documented  processes,  methods,  and 
tools  provide  assurances  to  the  customer  that  the  service  received  through  implementing 
the  SSB  system  is  repeatable,  continuous,  and  reliable.  These  documented  practices  have 
been  delineated  in  the  Systems  Engineering  Development  and  Implementation  (SEDI) 
Plan  (Appendix  B)  with  detailed  examples,  instructions,  templates,  processes,  etc.  which 
can  be  immediately  implemented.  The  LLC  reductions  are  offered  in  the  Business  Case 
Analysis  (Appendix  C)  with  detailed  financial  metrics.  Generally  speaking,  the 
characteristics  of  the  SSB  process  as  described  here,  makes  the  SSB  system  an  additional 
alternative  to  the  PMOs  in  resolving  obsolescence  issues.  However  it  differs  from  the 
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dozen  or  so  point  solutions  currently  available  in  three  distinct  ways:  1)  the  collaborative 
architecture  necessitates  the  use  of  close  partnerships  with  the  supply  base  and  includes 
these  entities  in  the  resolution  process  and  in  the  business  planning,  2)  the  Systems 
Engineering  approach  embedded  within  the  SSB  system  optimizes  on  the  LCC  and  long¬ 
term  support  providing  a  structure  spanning  all  functional  disciplines  life  cycle  elements, 
this  allows  other  point  solutions  to  be  incorporated  where  appropriate  to  achieve 
maximum  utility,  and  3)  the  SSB  system  when  used  at  the  appropriate  time  yields  the 
lowest  LCC  and  best  value  risk  management  process  for  COTS  products.  All  three  of 
these  attributes  impact  the  program’s  ability  to  provide  long-term  support  of  COTS 
products  and  are  reflected  in  the  evaluation  criteria  used  in  assessing  the  PMO’s 
accomplishments,  as  viewed  from  their  sponsors. 

Strength  2:  The  SSB  system  provides  new  supportability  options  to  the 

PMOs. 

The  SSB  system  reduces  the  amount  of  program  investment,  extends  the 

repair/depot  support,  and  establishes  methods  to  reduce  the  mean  logistic  delay  time  for 

supplier  supported  COTS  products.  The  investment  the  program  would  need  to  make  to 

cover  the  spares  required  over  the  supportability  period  will  be  drastically  different  when 

using  the  SSB  system’s  methods  and  processes,  as  compared  to  usual  method  of  support 

of  Life  of  Type  Buy  (LTB)  option.  Refer  to  Appendix  C  (Business  Cass  Analysis)  for  a 

detailed  discussion  and  comparison  of  various  support  scenarios.  The  potential  savings 

on  a  specific  item  may  seem  minor,  but  when  an  aggregate  of  cost  over  all  COTS 

products  on  a  given  program/system  is  rolled  up,  to  quantify  the  immediate  cost  to  the 

program,  the  amount  is  usually  staggering.  Additionally,  the  SSB  system  support  allows 

the  PMO  to  meet  budgetary  constraints  while  providing  long-term  supportability 

requirements.  The  close  partnership  with  the  supply  base  provides  insight  into  not  only 

the  obsolescence  issues  but  also  gives  the  Navy  the  chance  to  negotiate  for  long-term 

supplier  support  of  fielded  products  for  repair  and  maintenance.  The  experience  gained 

during  the  implementation  of  the  SSB  system  on  three  programs  showed  that  every  SSB 

participant  was  capable  and  willing  to  perform  these  needed  depot  functions.  The 

relationship  building  accomplished  as  part  of  the  SSB  implementation  process  also 

addressed  another  Lleet  need,  that  is  the  suppliers  would  be  capable  and  willing  to  help 
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with  quick  turnaround  times  for  field  returns.  Many  of  the  suppliers  are  willing  to  keep  a 
spare  COTS  item  on  their  shelf  to  replace  immediately  a  Fleet  returned  unit,  this  could 
bring  the  turnaround  time  to  days  instead  of  weeks  or  months.  The  key  to  success  here  is 
partnering  and  collaboration.  The  benefits  of  these  are  obvious  and  the  SSB  system  is  the 
only  alternative  that  institutionalizes  the  Navy-supplier  partnerships  through  a  well- 
defined  infrastructure  and  set  of  implementation  tools.  As  part  of  the  process  the  PMO 
(customer)  defines  the  supportability  boundary  criteria,  such  as  -  How  many  years  does 
the  fielded  system  require  support  till  the  next  tech  refresh  activity?  Only  the  SSB 
system  allows  the  customer  to  choose  the  length  of  support  desired,  all  other  support 
methods  are  reactive  and  as  such  require  the  program  to  react  with  a  point  solution 
constraining  the  possible  alternatives  and  associated  time  elements.  The  structures  set  in 
place  by  the  SSB  system  provides  additional  opportunities  for  the  PMO  to  perform 
business  planning  such  as  PPBS,  funding  allocations,  and  equipment  install  scheduling. 
The  System  Engineering  approach  inherent  in  the  SSB  system  provides  these  added 
benefits,  which  are  not  available  through  the  use  of  point  solutions. 

Strength  3:  The  SSB  system  provides  a  proactive  COTS  obsolescence  risk 

management  process. 

The  customer  has  a  need  to  support  fielded  systems  for  extended  periods  of  no 

less  than  5  years  but  support  could  be  required  up  to  15-20  years.  Since  COTS  products 

generally  have  life  spans  of  2-5  years  after  which  supportability  is  not  an  option  without 

some  type  of  intervention.  The  SSB  system  is  a  planned  intervention  that  is  based  on  the 

support  needs  as  identified  by  the  customer.  The  partnering  and  infonnation  sharing 

between  the  supply  base  and  the  Navy,  provides  insight  to  previously  undisclosed 

potential  obsolescence  risks  of  COTS  products.  Combining  this  new  knowledge  with  the 

SSB  infrastructures  yields  the  risk  management  methods,  processes,  and  tools  for  use  by 

the  PMO  to  proactively  address  the  inherent  COTS  risk  issues.  The  SSB  system  was 

specifically  designed  to  be  the  first  alternative  containing  architectural  elements  capable 

of  addressing  the  risk  issues  involved  with  COTS  products.  The  key  to  success  in 

managing  this  risk  is  the  use  of  a  systemic,  broad  based,  life  cycle  approach  to  deal  with 

the  entire  fielded  system.  These  key  elements  are  absent  when  using  the  point  solution 

approach  employed  by  the  other  alternatives.  The  SSB  system  is  the  only  practice, 
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known  to  the  authors,  which  provides  opportunities  to  the  customer  to  address  risks 

previously  identified  as  large  and  open-ended  programmatic  risks. 

Strength  4:  The  SSB  system  provides  the  infrastructure  to  enable  Business 
planning  and  Management  system  for  fielded  system  containing  COTS 
products. 

Management  of  fielded  systems  containing  COTS  products  has  historically  been  a 
very  difficult  and  unsuccessful  venture  for  PMOs.  Several  characteristics  of  the  COTS 
products  compound  the  management  efforts  and  make  it  exceedingly  difficult  to  maintain 
control  over  these  products,  the  major  exacerbating  attributes  are:  1)  the  OEM  controls 
the  configuration  of  the  product  and  may  change  it  without  notice,  2)  the  rate  of  change 
of  the  COTS  products  is  measured  in  months  (i.e.  <  18-24  months  product  life  cycle) 
whereas  Fleet  installation  is  measured  in  years,  and  3)  many  COTS  products  do  not  have 
long-term  support  available.  The  SSB  system  was  specifically  designed  to  address  these 
issues  -  “head  on”  -  with  methods  to  gain  the  configuration  knowledge  and  potentially 
freeze  that  configuration  if  needed,  and  finally  the  issue  of  long-tenn  support  and 
obsolescence  management  is  addressed  through  processes  and  tools  embedded  within  the 
system.  As  an  emergent  new  property  of  the  SSB  system  due  to  the  long-tenn  planning 
and  holistic  view  taken,  the  knowledge  gained  regarding  the  fielded  systems,  identifies 
the  input  data  necessary  to  perform  long-term  business  planning  such  as:  estimated  spares 
required  each  year  of  support,  an  estimated  dollar  value  needed  each  year  to  extend  the 
COTS  life  cycle,  and  the  total  amount  of  proposed  budgetary  requirements.  The  SSB 
system  provides  the  first  system,  which  yields  this  type  of  knowledge  that  is  based  on 
justifiable  detailed  infonnation  used  in  predicting  the  estimates. 

With  the  designed-in  and  emergent  properties  of  the  SSB  system  the  PMO 
(customer)  can  now  control,  manage,  and  plan;  the  physical  support  of  the  hardware 
along  with  the  business  support  (i.e.  the  PPBS,  resource  allocations).  No  point  solution 
alternatives  can  produce  these  systemic  characteristics  and  the  PMOs  have  been 
requesting  such  a  solution  with  no  implement  able  practices  identified  until  the  SSB 
system  was  introduced. 


78 


2.  Weaknesses 

Weakness  1:  The  SSB  system  is  a  new  system  with  a  very  small  track  record. 

The  first  issue  that  emerges  due  to  the  low  level  of  implementation  of  the  SSB 
system  is  a  concern  that,  regardless  of  the  outcome  of  the  first  implementation  efforts,  has 
the  system  been  adequately  tested  out  and  found  capable  for  every  or  most  every 
application.  Like  any  new  system  -  perfonnance  over  time  -  will  be  the  arbitrator  for  the 
inclusion  and  growth  of  the  SSB  system.  The  lack  of  long  standing  track  record  will 
impact  the  acceptance  of  the  system  by  well-established  support  teams,  who  are  typically 
conservative  and  slow  to  incorporate  new  approaches.  Although  the  point  solution 
alternatives  lack  many  desirable  characteristics  obtained  through  the  use  of  the  SSB 
system,  the  point  solutions  have  been  used  to  support  the  existing  fielded  systems  and 
therefore  have  a  proven  track  record  and  an  expected  outcome.  A  PMO  or  their  support 
team  will  need  to  perform  a  trade-off  analysis  with  regards  to  comparing  existing 
methods  and  solution  alternatives  with  the  SSB  system’s  attributes.  Depending  on  what 
criteria  is  used  and  who  is  making  the  decisions,  the  SSB  system  may  or  may  not  be 
considered  as  a  potential  alternative.  Possible  roadblocks  and  constraints  are  described  in 
the  “Competitive  Forces”  section  of  the  Marketing  Plan  and  provide  insights  to  the 
motivation  behind  some  group  or  person  wanting  to  exploit  this  weakness. 

Weakness  2:  The  SSB  system  necessitates  the  up-front  PMO  support  and  a 

long-term  commitment  on  behalf  of  the  PMO  and  the  support  team. 

The  SSB  system  is  built  on  a  collaborative  architecture  that  necessitates  the 
voluntarily  participation  of  its  members.  As  with  most  proactive  methodologies  the  SSB 
system  requires  some  up-front  investment  to  initiate  any  kind  of  return.  Typically  before 
the  PMO  will  invest  in  a  potential  alternative  they  will  want  to  know  what  kind  of  return 
can  be  expected  and  what  kind  of  risk  they  are  taking.  Compared  to  point  solution 
alternatives,  which  are  usually  singular  events,  the  SSB  system  requires  continuous 
support  over  the  life  cycle  of  the  fielded  COTS  products,  in  essence  locking  the  PMO 
into  a  long-term  commitment.  Both  the  up-front  support  and  the  long-term  commitment 
present  the  PMO  with  a  potential  risk  to  the  program  with  respect  to  funding  and 
technical  support  issues.  The  PMO  or  their  support  team  will  need  to  perform  a  trade-off 
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study,  formally  or  informally,  to  identify  the  cost-benefit  comparison  in  using  or  not 
using  the  SSB  system  on  their  specific  program.  The  approach  taken  in  performing  the 
trade-off  study  will  be  reflective  of  the  outcome.  If  the  approach  focuses  mostly  on  the 
short-term  results  with  little  attention  paid  to  the  long-term  outcome,  then  a  point  solution 
alternative  may  look  the  most  promising.  However  if  the  long-tenn  view  is  taken  and  the 
focus  is  on  LCC  and  reducing  programmatic  risk  the  most  probable  outcome  will  be 
implementing  the  SSB  system. 

Weakness  3:  The  SSB  system  is  not  part  of  the  mainstream  contracting 

process  implemented  by  NAVICP. 

When  a  PMO  tasks  NAVICP  to  contract  for  the  program  support  functions,  any 
Organic  activity  providing  DMSMS/obsolescence  support  functions  are  specifically 
excluded  from  participating  in  the  contracting  process;  this  exclusionary  policy  includes 
the  SSB  system.  Unless  the  PMO  has  an  awareness  of  the  situation  and  interjects  the 
desire  to  peruse  the  SSB  system  specifically,  the  SSB  system  will  not  even  receive 
consideration  as  a  possible  alternative.  As  identified  in  the  Marketing  Plan  under  the 
section  labeled  -  “The  Performance  Based  Contracting  Environment”  -  the 
implementation  policies  and  guidelines  imposed  by  NAVICP  do  not  allow  a  competitive 
environment  with  a  level  playing  field  and  constrain  Organic  activities  potential 
involvement  to  one  in  which  places  the  government  employee  in  a  “conflict  of  interest” 
position.  These  exclusionary  policies  directly  hinders  the  PMO  access  to  the  SSB  system 
and  provides  a  contracting  situation  in  which  the  Navy  may  not  have  the  potential  to 
receive  the  “best  value”  for  services  under  contract.  In  the  analysis  thus  far,  various 
solution  alternatives  were  compared  to  each  other  in  competing  for  resources,  however 
with  the  exclusion  of  all  potential  alternatives  except  as  deemed  appropriate  by  NAVICP 
the  situation  shifts  the  argument.  If  the  PMO  tasks  NAVICP  to  contact  for  the  support 
functions,  no  competitive  environment  exists  and  no  consideration  can  be  made  by  the 
PMO  regarding  the  utility  and  cost  effectiveness  of  the  SSB  system. 
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Weakness  4:  Implementation  of  the  SSB  system  will  require  a  cultural  shift 
from  an  independent  competitive  environment  to  a  collaborative 
interdependency  of  diverse  functional  groups. 

The  PMO  support  teams  that  have  already  been  established  to  take  care  of  the 
DMSMS  issues  and  are  quite  diverse  with  respect  to  the  teaming  methodology  while 
developing  their  current  cultures.  Many  of  these  teams  use  working  group  techniques 
where  work  is  accomplished  off  line  in  functional  silos  then  brought  to  the  team  for 
approval  expecting  only  minor  changes.  Some  of  the  support  teams  accomplish  their 
work  as  an  IPT  and  leverage  the  cross  functional  aspects  of  the  group.  Sometimes  the 
PMO  support  comes  from  independent  functional  silos  that  have  little  use  for  the  teaming 
atmosphere.  The  variations  of  the  support  efforts  are  to  numerous  to  mention  although 
there  seems  to  be  an  underlying  base  assumption  that  all  activities  and/or  functions  are 
vying  for  the  same  resource  pool  of  funding.  The  SSB  system  to  be  successful  must 
foster  an  atmosphere  of  a  “win-win”  scenario  and  staying  away  from  the  “zero  sum 
game”  so  prevalent  in  funding  resource  struggles.  The  SSB  system  will  need  inputs  from 
and  provide  outputs  to,  almost  every  function  on  the  support  team  and  therefore  the 
interdependency  relationships  need  to  be  established  and  matured.  The  lack  of  a  SSB 
system  friendly  environment  does  not  spell  out  failure  for  the  system  but  such  an 
environment  will  impede  implementation  progress  and  constrain  the  potential  benefits 
from  the  system.  The  comparison  between,  the  way  support  teams  currently  do  business 
and  the  practices  used  in  the  SSB  system  will  be  evident  over  time  and  will  be  unique  to 
each  team.  The  implementation  of  the  SSB  system  will  require  a  certain  amount  of 
cooperation  and  adjustment  but  these  changes  are  usually  possible  within  most  groups 
established  cultural  norms.  From  the  perspective  of  the  customer,  the  cultural  shift  is 
more  of  a  challenge  that  should  be  eventually  overcome  instead  of  a  “better  or  worse” 
attribute. 

3.  Opportunities 

Opportunity  1:  Meeting  the  PMO  objectives  in  providing  Life  Cycle  Cost 
(LCC)  reductions  of  50%  or  more  on  all  systems. 

The  LCC  is  one  of  the  primary  evaluation  criteria  placed  on  the  PMO  during  their 
annual  and  semiannual  reviews.  One  of  the  biggest  issues  the  PMO  faces  when 
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quantifying  the  LCC  is  in  defining  the  parameters  that  need  to  be  measured  and  tracked. 
The  structure  of  the  SSB  system  encapsulates  these  metrics  into  a  reporting  system  that 
keeps  the  PMO  abreast  of  the  projected  and  actual  costs  incurred  by  the  program  with  the 
added  benefit  of  incorporating  other  non-SSB  point  solutions.  In  this  way  the  PMO  has 
an  oversight  view  regarding  the  true  cost  of  support  of  the  programs  systems.  With  the 
results  of  the  three  pilot  programs  available  to  us,  we  can  take  these  results  and  draw 
comparisons  with  other  target  programs,  which  have  shown  interest.  The  three  example 
programs  were  specifically  chosen  because  each  represents  a  specific  part  of  the 
developmental  cycle  such  as:  the  20X  Sonar  Mine  Detecting  Set  program  is  just  finishing 
the  Engineering  and  Manufacturing  Development  (E&MD)  phase,  the  SSDS  MK  2  is  in 
the  Production  phase  with  less  than  one  eight  of  the  projected  units  fielded,  the  SSDS 
MK  1  is  considered  a  legacy  system  with  17  fielded  system  that  need  to  be  support,  as  is, 
for  the  next  10  years.  The  most  complete  data  set  we  have  compiled,  at  the  time  this 
paper  was  written  is  for  the  SSDS  MK  1  systems  although  the  data  for  the  other  systems 
are  still  being  compiled  and  so  far  seem  to  reflect  the  same  type  of  LCC  reductions  as 
experienced  with  the  MK  1  systems.  With  this  implementation  experience  we  can 
capitalize  on  the  fact  that  we  can  address  programs  regardless  of  where  in  the 
developmental  life  cycle  they  are,  and  we  can  use  the  captured  MK  1  data  set  to  show 
expected  reductions  in  LCC. 

Opportunity  2:  The  SSB  system  defines  pro-active  risk  management  methods 

for  COTS  products  that  provide  the  Fleet  user  with  the  assurance  that  their 

system  will  be  supportable  over  time  and  available  when  needed. 

Risk  management  like  LCC  is  an  evaluation  criterion  for  the  PMO  and  carries 
considerable  weight  with  their  resource  sponsors  in  obtaining  and  keeping  their  funding 
allocations.  The  SSB  system  is  the  only  post  design  pro-active  method,  known  to  the 
authors,  that  is  capable  of  yielding  a  quantifiable  COTS  obsolescence  risk  management 
method.  The  SSB  system  identifies  the  current  risk  state  and  a  projected  risk  state  in  a 
measurable  fashion  so  that  it  can  be  tracked  and  trended.  These  metrics  can  then  be  used 
by  the  PMO  as  objective  evidence  in  justification  of  the  funding  allocations.  Since  the 
risk  management  methods  are  an  inherent  part  of  the  SSB  system  and  reflected  in  the 
reporting  processes  and  tools  a  direct  analogy  can  be  made  with  any  new  potential 
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program  and  the  three  programs  successfully  implemented.  The  reporting  products  used 
on  the  three  programs  are  by  design  simple  graphical  representations  so  they  can  be 
readily  identifiable  by  the  PMO  representatives.  To  gain  the  most  leverage  out  of  the 
work  already  accomplished,  the  previously  prepared  risk  reports  will  be  briefed  to  any 
new  potential  candidate  programs  making  a  direct  comparison  between  the  benefits 
received  by  the  previous  program  and  the  candidate  program. 

Opportunity  3:  Growth  and  maturity  of  the  SSB  system  provides  greater 

opportunity  for  other  Navy  programs  to  leverage  this  unique  internal 

resource  expanding  its  value  proposition  to  the  Navy. 

The  first  programs  that  supported  the  implementation  of  the  SSB  system  had  no 
previous  work  to  leverage  from  and  therefore  needed  to  pay  for  each  relationship 
building  effort  and  every  configuration  assessment.  However  with  over  40  OEM 
relationships  established  and  analysis  of  over  100  configurations,  the  next  programs  to 
implement  will  more  than  likely  use  a  portion  of  the  previous  efforts.  The  expectation  is 
that  over  the  next  5-7  program  implementations,  the  amount  of  reuse  of  previous  work 
may  be  as  much  as  10-15%  of  the  total  effort.  The  implementation  efforts  which  follow 
are  expected  to  have  an  increased  percent  of  reuse  perhaps  eventually  yielding  as  much  as 
50%  reuse  in  later  implementation  efforts.  As  the  SSB  system  is  used,  implemented,  and 
matured  the  more  utility  the  programs  receive  from  it  and  the  programs  sponsors  will 
look  favorably  upon  the  use  of  the  system  since  it  was  their  resources  that  are  being 
reused  instead  of  being  spent  on  efforts  which  “reinvent  the  wheel”.  The  actions  that  are 
being  taken  to  exploit  this  reuse  characteristic  of  the  SSB  system  are  to  make  available 
the  list  of  OEM  participants  and  the  specific  configurations  that  the  SSB  system  was 
implemented  on.  On  a  personal  sell  level  we  use  the  current  listing  as  an  example  of  the 
potential  out  come,  then  identify  if  any  of  the  configurations  appearing  on  the  list  or 
OEM  names  on  the  list  are  a  match  to  the  new  potential  candidate  system.  If  an  exact 
configuration  match  takes  place,  we  offer  to  share  the  obsolescence  risk  analysis  with  the 
new  program.  If  further  interest  is  apparent  and  the  program  is  willing  to  engage  further 
analysis,  we  could  work  with  program  representatives  to  prepare  risk  mitigation  report 
specific  to  the  program’s  needs  (i.e.  part  number  obsolete,  how  many  parts  per  assembly, 
how  many  assemblies  per  new  system,  how  many  new  systems,  how  long  is  the  expected 
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support  window,  etc.)  A  quick  demonstration  of  the  SSB  systems  capabilities  will 
illustrate  to  the  program  the  real  utility  of  the  infonnation  and  the  subsequent  knowledge 
gained  through  its  use.  In  order  to  reach  a  large  or  mass  audience  with  this  information, 
we  have  near  term  plans  to  post  the  information  on  a  web  site  used  by  our  target 
audience.  The  GIDEP  (Government  Industry  Data  Exchange  Program)  web  site 
(www.gidep.gov)  has  over  1,500  membership  organizations  boasting  a  user  pool  of  over 
4,500  individual  users.  During  the  mil  speck  era  before  Acquisition  Reform,  membership 
in  this  system  was  one  of  the  acquisition  requirements  for  all  Navy  programs  and  their 
prime  contractors;  therefore  most  of  our  potential  new  program  candidates  will  have 
access  to  this  system.  The  GIDEP  organization  has  agreed  to  host  a  list  of  OEM 
participants  and  the  specific  configurations  contained  in  the  current  SSB  system  active 
participation  lists.  All  presentation  materials  and  future  announcements  will 
subsequently  be  updated  to  reflect  this  reference  whereby  it  can  be  tapped  as  a  ready 
reference. 

Opportunity  4:  The  SSB  system  employees  several  simulation  and  modeling 

tools  to  optimize  the  business  planning  and  future  support  requirements  for 

fielded  program  systems. 

As  part  of  the  implementation  effort  regarding  the  SSB  system,  detailed  resource 
and  procurement  models  were  prepared  for  the  SSDS  MK  1  system  from  which  various 
scenarios  can  be  simulated  iteratively  and  recursively  showing  the  possible  outcomes.  It 
can  easily  be  demonstrated  that  the  structure  of  these  tools  allows  modification  and 
customization  to  be  applicable  to  most  any  program.  Furthermore  the  results  of  running 
the  various  models  using  the  SSDS  MK  1  data  provides  a  stunning  real  life  example  of 
the  positive  results  attainable  through  SSB  system  implementation.  To  the  authors’ 
knowledge,  no  other  system  or  method  has  identified  a  method  to  work  within  the  PPBS 
funding  system  to  support  an  overarching  DMSMS  support  system.  These  models  are 
tailored  to  reflect  the  requirements  of  the  PPBS  system  such  that  the  outputs  from  the 
models  could  be  directly  transferred  to  the  Funding  Allocation  Request  (FAR)  an  input  to 
the  PPBS  system.  The  procurement  models  identify  within  the  constraints  leaved  by  the 
program,  the  expected  level  of  support  with  regards  to  the  hardware  for  each  year  of 
support.  These  levels  are  predicted  based  on  the  actual  failure  rate  exhibited  in  the  Fleet. 
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The  resource  modeling  is  accomplished  using  the  NSWC  Crane  cost  model,  which  takes 

into  account  all  the  various  aspects  of  implementing  an  Engineering  Change  Proposal 

(ECP).  This  model  covers  over  128  functions/activities  and  is  tailored  to  meet  the  needs 

of  the  application  under  consideration.  Between  these  two  models  and  a  few  other  tools 

used  in  the  SSB  system,  the  program  can  get  the  “Big  Picture”  view  of  the  supportability 

requirements  for  their  program.  Every  program  has  a  requirement  to  substantiate  and 

justify  their  business  planning  (funding  and  allocation),  support  strategy,  and  risk 

management  efforts.  Knowing  these  requirements  and  the  inherent  capabilities  of  the 

SSB  system,  which  are  designed  into  the  system  to  meet  the  program  needs  must  be 

communicated  when  presenting  the  system  to  a  candidate  program.  Again  the  use  of  the 

SSDS  MK1  data  set  in  the  models  then  running  simulations  structured  around  the 

constraints  of  the  candidate  program  can  be  an  illustrative  and  convincing  tool.  These 

simulations  can  be  run  quickly  providing  immediate  results  to  show  the  new  candidate 

program  that  the  constraints  presented  by  their  program  can  fit  within  the  modeling 

structure.  In  showing  the  applicability  of  the  tool  and  methods  within  the  confines  of  the 

candidate  program  will  provide  them  some  assurance  of  potential  success.  The 

confidence  gained  through  these  demonstrations  may  be  enough  to  bridge  the  gap  and 

provide  a  comfort  level  great  enough  to  make  the  up-front  commitment  and  provide 

adequate  resources  to  implement  the  SSB  system  on  their  program. 

Opportunity  5:  The  Naval  Audit  Service  (NAS)  has  recently  released  reports 
indicating  that  the  implementation  of  the  Contractor  Logistic  Support  (CLS) 
contracting  methodologies  used  by  NAVSEA  and  SPAWAR  lacks  adequate 
visibility  and  metrics  that  would  assure  proper  oversight. 

The  NAS  report  numbers  N2002-0049  [17)  NAS  NAVSEA]  and  N2002-0069 
[18)  NAS  SPAWAR]  both  identify  a  lack  of  a  performance  plan,  strategy,  or 
management  control  to  implement  the  CLS  acquisition  refonn  initiative  by  NAVSEA  and 
SPAWAR  respectively.  The  lack  of  controls  and  measurements  to  achieve  the  desired 
results  of  reduced  cost  and  improve  system  availability  was  identified  as  an  inadequacy 
in  Program  Management.  CLS  can  and  many  times  does  take  into  account  the  DMSMS 
support  functions  usually  in  the  fonn  of  Performance  Based  Logistics  (PBL)  contracting 
methods.  As  discussed  earlier  in  this  plan,  PBL  contracting  methods  do  not  provide  the 
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most  advantageous  environment  for  the  Organic  field  activities  participation  including 
the  use  of  the  SSB  system.  Both  SYSCOMs  (NAVSEA  &  SPAWAR)  need  to  develop 
reporting  and  management  structures  to  overcome  the  identified  shortcomings. 

The  BCA  prepared  in  support  of  the  SSB  system  in  conjunction  with  the  reporting 

mechanisms  inherent  to  the  SSB  system  will  meet  these  shortcomings  reported  by  NAS. 

The  reporting  and  management  structures  needed  by  the  SYSCOMs,  have  already  been 

set  up  and  are  functioning,  available  only  if  the  programs  choose  to  implement  the  SSB 

system.  The  SYSCOMs  management  and  the  Program  Managers  need  to  be  informed  of 

the  availability  of  the  SSB  system  in  order  to  leverage  the  currently  available  assets.  This 

additional  attribute  of  the  SSB  system  should  be  announced  at  the  same  time  we 

communicate  the  potential  negative  impacts  when  CLS  or  PBL  are  implemented  through 

NAVICP  using  their  exclusionary  implementation  practices. 

Opportunity  6:  In  early  September  2002  Secretary  of  Defense  office 
rescinded  the  existing  DoD  5000  series  documents  with  a  memo  that  stated, 
the  identified  hard  requirements  -  the  “must  do”  -  Systems  Engineering 
methods  will  be  replaced  by  a  guidance  document  to  provide  more  leeway  to 
the  Program  Managers[19)DJSM]. 

The  removal  of  requirements  documents  relaxes  the  discipline  required  by  the 
implemented  processes  and  inevitably  produces  larger  risks  to  the  Program  Manager 
(PM)  and  the  acquisition  process.  To  be  successful  in  a  requirements  poor  environment 
the  PM  must  institute  risk  management  methods  and  practices  to  maintain  control  or  at 
least  visibility  into  the  program  activities.  With  this  new  change  of  direction  from  DoD 
the  need  for  the  risk  management  disciplines  increases  dramatically  and  must  be 
instituted  on  a  continuous  ongoing  basis. 

The  communications  with  the  customer  base  should  identify  the  obsolescence  risk 
management  attributes  of  the  SSB  system  and  how  these  attributes  provide  the  PM  with 
the  visibility  into  the  program  activities.  One  of  the  keys  to  illustrating  the  utility  of  the 
system  will  be  in  displaying  reporting  products  from  previously  assessed  COTS  products 
on  other  programs  especially  if  they  are  also  used  on  the  PMs’  equipment.  The 
continuous  and  all  encompassing  insight  provided  through  the  reporting  mechanisms  as 
part  of  the  SSB  system  are  packaged  and  tailored  to  meet  the  needs  of  the  program. 
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4.  Threats 

Threat  1:  Current  contracting  implementation  policy  regarding  Performance 
Based  Contracting  (PBC)  may  curtail  or  eliminate  the  possibility  of  using  the 
SSB  system. 

As  identified  in  the  preceding  material  the  implementation  policies  of  NAVICP 
can  preemptively  exclude  the  participation  of  all  Organic  activities  and  therefore  exclude 
the  SSB  system.  The  PMO  may  unknowingly  task  NAVICP  to  subcontract  out  the 
DMSMS  support  functions  believing  that  the  “best  value”  for  their  program  will  result 
from  a  competitive  environment.  As  discussed  in  detail  in  the  Marketing  Plan,  NAVICP 
does  not  provide  a  competitive  environment  nor  do  their  processes  assure  “best  value”, 
therefore  without  prior  knowledge  of  the  contracting  environment  or  intimate  knowledge 
of  the  capabilities  of  the  SSB  system  the  programs  may  never  know  of  these 
shortcomings.  NAVICP’s  exclusionary  policies  are  either:  1)  an  unintended  consequence 
of  their  goal  to  streamline  their  processes,  or  2)  a  sub  optimization  that  optimizes  their 
processes  while  in  the  grander  scheme  of  things  does  not  provide  the  Navy  with  the  “best 
value”.  Regardless  of  the  reason  or  logic  behind  these  policies  the  impact  of  them  needs 
to  address.  A  three  pronged  approach  is  recommended  in  dealing  with  the  current 
situation:  1)  address  NAVICP  directly  through  a  set  of  meeting  with  the  decision  makers 
to  illustrate  the  impacts  of  the  policies  and  show  bottom  line  figures  from  implemented 
examples  of  the  SSB  system  and  show  what  the  Navy  is  missing  out  on  because  of  their 
policies,  hopefully  resulting  in  a  change  in  policy  direction,  2)  since  it  has  been  shown 
(see  Marketing  Plan,  Appendix  D)  that  their  policies  are  in  conflict  with  the  guidance 
documents  and  executive  mandates,  that  a  request  for  clarification  be  sent  to  Secretary  of 
the  Navy,  Advocate  for  Competitive  Environment  and  have  NAVICP  implementation 
policies  reviewed  for  adequacy  and  possible  revision,  and  3)  develop  a  mass  broadcast  to 
all  PMO  and  provide  them  with  intimate  knowledge  of  the  SSB  system  and  specifically 
highlight  the  shortcomings  of  the  NAVICP  implementation  policies.  All  three  of  these 
approaches  are  being  undertaken  at  this  time.  With  the  completion  of  the  Business  Case 
Analysis  (BCA)  as  a  result  of  the  SSB  system  implementation  process  for  SSDS  MK  1, 
we  will  have  accurate  real  data  to  prove  the  viability  of  the  SSB  alternative  and  with  that 
data  we  can  approach  NAVICP  with  a  supportable  and  justifiable  case  in  point.  A  set  of 
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clarification  questions  have  been  prepared  and  is  being  sent  to  the  point  of  contact  in  the 
SECNAV  office  to  review  our  interpretations  of  the  cause  and  effect  impacts  due  to  the 
NAVICP  implementation  policies.  Articles  are  being  prepared  for  three  separate 
publications  well  read  by  our  target  audience:  1)  The  COTS  Journal,  2)  Defense 
Acquisition  University  (DAU)  -  Acquisition  Review  Quarterly,  and  3)  Defense 
Acquisition  University  -  Program  Manager,  PM  Magazine.  Additionally  several 
conferences  and  workshops  have  been  or  will  be  presenting  the  SSB  system  during  the 
event  and  the  presented  materials  will  be  contained  as  part  of  the  proceedings.  With 
regards  to  the  long  term  mitigation  of  this  treat,  our  plans  are  to:  1)  Institutionalize  the 
SSB  system  as  a  standard  alternative  by  updating  the  DAU  publication  -  Program 
Managers  Handbook  -  to  reflect  the  SSB  system  as  the  preferred  practice,  2)  keep 
vigilant  with  regard  to  the  DMSMS  community  by  providing  presentations  at  future 
conferences/workshops,  3)  provide  face  to  face  presentations  to  as  many  programs  as 
possible,  thus  far  over  a  dozen  such  presentations  have  been  given,  4)  present  to  the 
Program  Executive  Offices  (PEO)  and  resource  sponsors  showing  the  bottom  line 
benefits  to  get  a  top  down  endorsement/sponsorship. 

Threat  2:  Subcontracting  government  DMSMS  support  personnel  to 

contractors  creates  a  “conflict  of  interest”  situation  for  the  government 

employee  while  yielding  sub  optimal  results  for  the  Navy. 

The  primary  purpose  in  implementing  the  SSB  system  is  to  provide  the  “best 
value”  to  the  Navy  through  defining  a  process  yielding  manageable  risks  at  the  lowest 
LCC.  If  a  “conflict  of  interest”  situation  exists  either  within  the  contractor  -  the  bottom 
line  versus  “best  value”  for  the  Navy  -  or  with  the  government  employee  trying  to 
balance  the  requirements  of  -  their  employer  directives  versus  “best  value”  for  the  Navy 
-  the  lack  of  independence  of  DMSMS  support  function  will  most  likely  produce  sub 
optimal  results  for  the  Navy.  Since  the  NAVICP  implementation  policies  have  no  counter 
acting  force  or  “change  agent”  activists,  contracting  out  this  vital  function  appears 
inevitable.  Over  time  the  internal  Organic  activities  will  become  either  the  willing 
participants  of  the  contractor’s  directives  or  a  non-participant  whereby  the  internal  Navy 
resources  for  DMSMS  support  will  eventually  disappear.  In  the  end  the  PMO  (customer) 
will  receive  DMSMS  support  that  will  reflect  the  contractor’s  -  “best  bottom  line”  - 


versus  the  Navy’s  -  “best  value”.  The  same  action  plan  identified  for  Threat  1  is 
applicable  with  regard  to  the  “conflict  of  interest”  issues  although  a  few  actions  will 
require  modification.  With  a  “conflict  of  interest”  problem  the  issues  take  on  more  of  a 
political  overtone  versus  the  straight  business  implications  in  arriving  at  the  “best  value” 
for  the  Navy,  as  identified  in  Treat  1.  Therefore  it  is  important  to  work  this  issue  in  a 
low-key  fashion  up  the  chain  of  command  instead  of  broadcasting  it  at  every  conference 
and  workshop.  The  preventative  actions  to  mitigate  this  treat  are  to  confront  NAVICP 
directly  and  request  interpretation  and  action  from  SECNAV. 

5.  Contributions  to  Business  Objectives 

a)  Financial  and  Business  Performance 

The  implementation  of  the  SSB  process  to  the  SSDS  program  has  had 
positive  impacts  to  both  the  financial  and  business  perfonnance  requirements.  The  SSB 
process  essentially  provides  an  architecture  that  specifically  addresses  the  issue  of 
obsolescence,  diminishing  manufacturing  sources,  and  material  shortages.  In  this  way  the 
risk  to  the  program  is  significantly  reduced.  The  architecture  provides  effective 
coordination  and  networking  leading  to  tremendous  cost  savings  as  well  as  the  ability  to 
ensure  long-term  supportability  for  COTS  products.  From  a  financial  perspective,  the 
SSB  process  allows  for  the  opportunity  to  significantly  reduce  the  upfront  costs  and 
stabilize  the  funding  profile  over  the  period  of  support  leading  to  a  much  more  efficient 
use  of  funds.  This  is  in  addition  to  sizeable  cost  savings  and  avoidance.  From  a  business 
perspective,  the  overall  awareness  of  obsolescence  and  material  shortages  gives  the 
program  manager  more  information  for  making  effective  decisions.  Furthermore,  the  risk 
mitigation  aspects  of  the  SSB  process  come  from  establishing  a  collaborative 
environment  where  the  responsibilities  and  risks  are  shared  between  the  commercial  and 
government  activities.  Out  of  this  environment  come  positive  business  impacts  in  terms 
supportability,  program  planning,  program  risk  and  Life  Cycle  Cost. 

b)  Strategic  Positioning  and  Ownership 

The  SSB  infrastructure  was  implemented  into  the  SSDS  program.  The 

overall  environment  is  one  of  collaboration,  coordination  and  trust.  The  functions  are 

coordinated  across  a  network  of  commercial  and  government  activities.  The  expertise 
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from  both  the  private  and  public  sectors  is  shared  across  this  network.  This  situation 
nurtures  long-term  relationships  between  the  commercial  entities  and  the  DoD 
participating  activities.  These  relationships  are  consistent  with  present  DoD  and  industry 
partnering  initiatives.  This  and  the  fact  that  the  SSB  process  has  provided  tremendous 
cost  savings  to  the  SSDS  program  only  strengthens  the  strategic  position  of  the  SSB 
system  within  the  set  of  support  alternative  solutions  presently  available  to  the  PMO. 
Furthermore,  the  mere  fact  that  the  PMO  has  discretion  and  authority  to  create  an  SSB 
environment,  illustrates  the  control  and  ownership  the  PMO  has  in  the  face  of  COTS 
product  proliferation.  Remember,  the  COTS  initiative  essentially  reduces  the  control  the 
DoD  has  historically  had  over  system  design  and  support.  The  SSB  process  allows  the 
Program  Office  to  regain  some  control  in  that  it  extends  supportability  and  maintains  key 
technologies  for  stabilizing  the  system  baseline. 

c)  Operations  and  Functions 

Reviewing  the  benefits  that  are  derived  by  implementing  the  SSB  process, 
we  immediately  realize  the  positive  effect  it  has  on  extending  COTS  product 
supportability  for  the  SSDS  program.  Recall,  that  commercial  product  life  cycles  are 
typically  18-months  to  2-years,  whereas  DoD  planning  and  implementation  easily 
exceeds  5  years.  In  this  case  the  SSB  process  allowed  the  PMO  to  postpone  likely 
redesigns  that  result  from  obsolescence.  By  extending  supportability,  the  SSB  process 
gives  the  PMO  the  opportunity  to  better  forecast  and  react  to  changes  in  warfighter 
requirements  as  well  as  in  the  market.  Overall  management  of  the  program  is  made  more 
efficient  given  the  extended  timeframe  for  assessing  technology  trends  and  evolving 
warfighter  requirements.  By  extending  COTS  product  supportability,  the  PMO  can  now 
align  technology  refresh  cycles  with  product  end-of-production  dates.  In  this  case  we  are 
talking  about  the  extended  production  of  a  specific  COTS  product  by  the  Sunset  Supplier. 
At  the  same  time  we  can  essentially  compress  the  timeframe  for  delivering  support  to  the 
warfighter.  Sunset  Suppliers  take  on  the  responsibility  of  stockage,  storage,  and  issue  of 
COTS  replacement  and  repair  parts.  Improved  delivery  to  the  warfighter  is  expected 
since  the  Sunset  Supplier  can  be  contractually  responsible  for  specific  perfonnance 
metrics  if  so  stated  in  the  appropriate  documents. 
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d)  Product  and  Services 

With  the  implementation  of  the  SSB  process,  key  enabling  technologies 
are  retained  through  extended  supportability  over  a  defined  period  of  time.  The  net  result 
is  a  stabilized  system  performance  baseline  produces  an  overall  improvement  in  terms  of 
products  and  services.  The  SSB  process  allows  the  program  manager  to  match  the  COTS 
product  update  cycles  with  the  program’s  technical  roadmap  or  refresh  effort. 
Furthermore,  as  a  product,  the  SSB  infrastructure  becomes  part  of  a  toolset  that  provides 
obsolescence  indicators  and  reports  as  well  as  the  ability  to  mitigate  maintenance  and 
supportability  issues  at  the  assembly  level.  This  support  strategy  can  now  include  a 
mechanism  for  establishing  and  managing  the  information  obtained  from  the  assessment 
and  reporting  activities,  thus  empowering  the  program  manager  with  the  knowledge 
necessary  to  deliver  an  improved  customer  service.  In  the  long  run  the  system  integrity  is 
maintained,  which  has  several  implications  in  terms  of  Integrated  Logistical  Support 
(ILS)  (i.e.  training,  manuals,  configuration  control,  Fleet  training...) 

e)  Image 

The  financial  and  non-financial  benefits  derived  and  identified  within  this 
document  prove  the  viability,  effectiveness  and  value  of  the  SSB  system  as  an  alternative 
to  conventional  support  mechanisms  such  as  “Life  of  Type  Buy”  (LTB).  Not  necessarily 
as  a  replacement  for  these  traditional  methods  the  SSB  system  supplements  them  as 
another  option.  The  SSB  process  does  not  intend  to  extend  supportability  for  the  sake  of 
retaining  old  technology,  but  rather  to  stabilize  the  system  perfonnance  baseline  for 
periods  that  can  be  aligned  with  DoD  acquisition  cycles.  It  offers  an  opportunity  for  the 
PMO  to  consider  redesigns  based  on  performance  enhancements  in  response  to  evolving 
warfighter  requirements  rather  than  redesigns  due  to  obsolescence.  This  mere  fact  makes 
this  an  attractive  scenario  from  a  PMO’s  perspective  for  improving  life  cycle 
management.  And  in  conjunction  with  the  significant  cost  savings  the  overall  appeal  of 
the  SSB  system  should  make  it  the  alternative  of  choice  for  program  managers  seeking  to 
optimize  their  support  strategy. 
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6.  Summary 

The  results  presented  within  this  document  clearly  illustrate  that  the  SSB 
implementation  has  the  potential  to  offer  significant  benefits  to  DoD  Weapon  System 
acquisition  programs.  Nevertheless,  the  results  not  only  reflect  an  overall  cost  savings 
for  the  analysis  period,  they  also  provided  further  insight  to  other  desirable  benefits.  In 
particular,  risk  mitigation  and  management  was  enhanced  for  the  program  manager.  The 
SSB  method  had  an  extremely  low  initial  investment  as  well  as  a  profoundly  stable 
funding  profile  over  the  defined  support  period.  The  low  initial  cost  translated  into  less 
of  upfront  investment.  The  more  money  that  is  invested  upfront,  the  more  you  are  locked 
into  a  situation  in  order  to  derive  the  greatest  return.  For  example,  let  us  say  that  you 
purchase  a  million  dollars  worth  of  spares  in  the  first  year  in  an  effort  to  support  a 
particular  product  over  ten  years.  After  the  first  two  years  you  use  up  $200K  of  the 
spares  when  you  are  presented  with  an  opportunity  to  improve  product  support,  reduce 
costs  and/or  enhance  system  capabilities.  You  still  have  $800K  invested  in  spares.  In  this 
case  you  are  unlikely  to  take  advantage  of  this  opportunity.  Subsequently,  low  initial  cost 
reduces  the  risk  of  staying  the  course  and  fully  optimizing  program  attributes. 
Furthermore,  in  the  situation  where  you  have  made  significant  investment  in  spares 
upfront,  you  are  calculating  this  amount  based  on  a  forecast  of  failures  for  a  particular 
item.  There  are  two  risks  associated  with  this.  First,  investing  too  much  means  making 
purchases  in  spares  that  will  never  be  used.  Second,  buying  too  little,  runs  the  risk  of  not 
being  able  to  support  the  weapon  system  for  the  prescribed  period  of  support.  Along  with 
the  low  initial  costs,  the  SSB  method  allows  for  even  expenditures  of  the  remaining 
funds.  To  whatever  degree  the  SSB  was  implemented,  the  resulting  funding  profile  was 
very  stable.  This  stability  is  important  to  the  planning  and  budgeting  process.  Effective 
planning  and  budgeting  is  essentially  a  process  in  risk  mitigation,  and  anything  we  can  do 
to  help  the  planning  and  budgeting  process  helps  us  to  reduce  risk.  Also,  remember  the 
very  nature  of  the  SSB  infrastructure  is  a  collaborative  venture  in  which  responsibility 
and  thus  risk  is  shared  between  the  commercial  and  government  entities,  a  further  step  in 
risk  reduction.  Furthermore,  by  stabilizing  the  funding  profile  we  can  make  efficient  use 
of  funds,  which  is  a  recurring  mandate  throughout  government  acquisition  directives. 
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The  effects  of  SSB  implementation  have  clear  financial  impacts,  which  are  aligned  with 
Federal  and  DoD  initiatives,  regulations  and  guidelines. 

The  financial  aspects  of  SSB  implementation  are  not  enough  to  conclude  it  as  a 
viable  support  solution  alternative.  Just  because  we  can  save  money,  we  have  to  ensure 
that  it  meets  the  requirements  of  the  program  and  ultimately  the  warfighter  as  well.  The 
SSB  process  extends  the  supportability  and  reparability  of  COTS  products.  By 
establishing  arrangements  between  Navy  Activities/Resources,  the  OEMs  and  third  party 
small  businesses  (Sunset  Suppliers),  we  can  provide  insurance  to  the  Program  Office  that 
a  particular  COTS  product  will  be  sustained  for  a  defined  period  of  time.  In  fact,  delivery 
of  the  replacement  spare  is  initiated  at  the  time  of  failure  in  the  Fleet.  The  COTS  item  is 
purchased  on  demand  rather  than  upfront,  which  is  based  on  failure  rate  data.  If  ten  items 
fail  over  ten  years,  you  will  only  purchase  ten  replacement  items.  This  approach  again  is 
flexible  and  provides  a  mechanism  for  improving  the  planning  and  budgeting  in  support 
of  the  next  tech  refresh  point.  The  extension  of  support  stabilizes  the  system  baseline  so 
that  a  more  focused  approach  is  given  to  planning  for  future  product  or  system  redesign 
efforts.  By  stabilizing  the  system  baseline  for  a  defined  period  of  time,  we  again  reduce 
risk  to  COTS  obsolescence  during  this  period.  In  fact,  the  very  SSB  infrastructure 
facilitates  effective  obsolescence  and  material  shortage  assessment  and  reporting.  This 
assessment  capability  is  a  coordinated  effort  across  the  SSB  infrastructure.  As  the  SSB  is 
implemented  on  more  programs  membership  in  the  SSB  process  grows  allowing  greater 
access  to  programs  Navy-wide.  In  effect,  the  data  collected  in  one  program  is  likely 
valuable  to  other  programs  given  the  growing  proliferation  of  COTS  products  in  military 
applications.  Therefore  we  visualize  a  process  that  is  transportable,  repeatable  and 
expandable  for  all  DoD/Navy  programs. 

As  mentioned,  certain  strengths  and  weaknesses  have  been  derived  from  actual 
implementation,  business  case  analysis  and  environmental  analysis.  These  strengths  and 
weaknesses  as  well  as  the  opportunities  and  threats,  give  great  insight  and  decision¬ 
making  power  for  focusing  implementation  activities  into  areas  where  the  SSB  is  strong, 
and  where  the  greatest  opportunities  lie.  The  information  presented  above,  is  pulled 
directly  from  Appendix  D  (SSB  Marketing  Plan),  which  also  provides  a  path  for 
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matching  SSB  strengths  to  its  opportunities  for  enhancing  SSB  system  capabilities  in 
supporting  the  DoD  Program  Management  Offices.  This  strategy  improves  the 
marketability  as  well  as  effectiveness  of  the  SSB  system.  Additionally,  Appendix  D 
offers  a  plan  for  converting  its  weaknesses  into  strengths  and  threats  into  opportunities. 
Overall,  based  on  the  analytical  results  and  guidance  provided,  a  strong  marketing 
strategy  has  been  developed  that  is  focused  on  capturing  20%  of  the  market  share  for 
Navy  programs  by  clearly  establishing  an  image  for  the  SSB  system,  through 
substantiated  benefits,  as  the  preferred  alternative  for  the  PMOs  in  supporting  weapon 
systems  that  use  COTS  products.  This  strategy  also  emphasizes  the  ability  of  the  SSB 
process  to  cost  effectively  insert  technology  into  fielded  Navy  systems.  A  key  element 
considering  the  transition  to,  and  growth  of,  COTS  products. 

The  results  from  the  four  deliverables  have  been  melded  together  in  this  section  in 
an  effort  to  provide  linkage  and  alignment  across  each  step  of  the  overall  thesis  approach. 
Many  benefits  have  surfaced  from  each  deliverable  (see  Appendix  A  -  D)  regardless  of 
the  approach  taken.  Also,  unique  strengths  or  benefits  have  been  extracted  from  the 
collection  of  all  the  deliverables  that  show  emergent  properties  not  necessarily  evident 
from  any  one  approach,  thereby  yielding  an  important  property  of  a  “System  of 
Systems”.  To  this  end,  we  see  that  each  deliverable  is  capable  of  standing  alone  as  a 
valuable  entity  for  use  in  the  decision-making  process  for  SSB  system  acceptance  and 
execution,  but  together  they  form  a  complete  offering  for  effective  and  successful  SSB 
implementation. 
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V.  CONCLUSION  AND  RECOMMENDATIONS 


A.  CONCLUSION 

1.  General 

This  paper  has  demonstrated  that  the  SSB  system  is  an  affordable  approach  for 
managing  and  mitigating  program  supportability  risk  due  to  COTS  products.  As  a 
collaborative  system,  the  information  that  is  derived  from  the  identification  and 
mitigation  of  risk  is  quantifiable  and  will  be  readily  accessible  to  all  SSB  team 
participants.  The  process  takes  into  account  the  fact  that  the  supportability  of  fielded 
hardware  is  defined  by  the  warfighter.  The  SSB  system  extends  the  life  cycle  and 
supportability  of  COTS  and  ensures  a  late-life  cycle  supply  source.  In  so  doing,  the  SSB 
pennits  DoD  to  be  successful  in  leveraging  commercial  developments  with  appropriate 
economies  of  scale  in  order  to  reach  its  military  performance  goals  while  offsetting  the 
problem  of  diminishing  material. 

The  SSB  system  assists  the  Program  Management  Office  (PMO)  by  providing 
infrastructure  support  to  existing  platforms/combat  systems.  When  implemented  early  in 
the  development  process,  the  SSB  process  has  been  demonstrated  to  extend  COTS 
products  availability  to  support  existing  weapon  systems;  thus  providing  significant 
reductions  in  program  risk  related  to  COTS  and  life  cycle  management.  The  SSB 
provides  predictive,  “decision  quality”  infonnation  for  PMO  decision-making  processes. 
The  outputs  of  trade-offs  and  assessments  accomplished  as  part  of  the  SSB  system  will 
gain  the  PMO  a  high  level  of  confidence  with  the  warfighter/customer.  The  process  is 
applicable  to  various  DoD  entities  and  their  business,  contract,  and  support  strategies. 
When  aggressively  integrated  across  DoD,  COTS  product  commonality  will  lead  to 
flexible  Integrated  Logistical  Support  (ILS),  thus  providing  incentives  for  the  commercial 
industry  to  develop  long-term  relationships  with  the  sponsors  and  users. 

The  SSB  is  sensitive  to  proprietary  design  rights  and  provides  a  proactive  forum 

for  contractual  negotiations.  The  method  employed,  improves  the  detection  of  product 

supportability  problems  and  provides  sufficient  time  for  analysis  of  alternatives  and 

solutions  in  the  decision-making  processes.  This  technology  assessment  can  be 
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implemented  at  the  piece  part,  lowest  replaceable  unit,  subsystem  or  multiple  platform 
level.  The  SSB  approach  is  to  procure  assemblies  when  the  customer  requires  them.  In 
this  way,  it  achieves  significant  and  quantifiable  cost  savings  over  the  product  life  cycle. 
The  process  provides  cost  structures  that  track  and  continually  assess  progress  over  the 
entire  product  life  cycle.  This  information  pennits  informed  decision-making 
contributing  to  life  cycle  cost  savings  without  the  need  for  Life  of  Type  Buys  at  the 
assembly  level. 

Use  of  the  SSB  system  improves  schedule  flexibility  by  providing  support  options 
that  can  be  tailored  for  the  activities  needed  and  the  warfighter.  It  reduces  provisioning 
timeframes  and  places  the  responsibility  for  stockage,  storage,  and  issue  of  COTS  spares 
and  repair  parts  on  the  supply  contractor.  SSB  enables  many  support  activities  and 
functions:  immediate  supportability  for  Fleet  returned  failures,  elimination  of  government 
inventory  stock  levels,  large  commercial  distribution  systems,  no  source  inspection, 
commercial  packaging,  fast  and  direct  delivery  to  the  warfighter,  and  warranty  of 
components.  The  SSB  process  has  definable  and  repeatable  characteristics  that  provide  a 
comprehensive  and  flexible  solution  to  supporting  fielded  hardware.  It  provides 
programs  with  an  independent  utility  for  implementing  COTS  products  and  has  minimal 
or  no  impact  on  system  operational  performance.  Once  implemented,  the  SSB  is  an 
affordable,  expandable,  repeatable  and  reliable  process  that  will  meet  the  users 
performance  expectations.  It  provides  the  best  of  both  worlds.  It  leverages  the  inherently 
governmental  functions  of  the  Navy  supply  process  and  coordinates  with  commercial 
supportability  assets  through  a  thoroughly  meshed  and  maintainable  communication 
network  solution. 

2.  Impacts  to  Problem  Statement 

The  overall  acquisition  of  military  weapon  systems  is  a  challenging  endeavor  to 
say  the  least.  One  thing  that  has  been  reported,  and  confirmed  in  the  business  case 
analysis,  is  that  procurement  costs  make  up  more  than  half  of  the  acquisition  costs.  In 
fact,  the  procurement  costs  incurred  after  a  system  has  been  fielded  still  accounts  for  the 
majority  of  the  life  cycle  costs.  This  scenario  has  lead  DoD  to  begin  leveraging 
commercial  standards,  products  and  practices  in  an  attempt  to  lower  risk  and  life  cycle 
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costs.  The  use  of  COTS  products  has  made  great  strides  to  reducing  initial  costs  while 
transferring  state-of-the-art  technologies  to  the  warfighter.  However,  these  gains  have 
come  with  their  own  set  of  problems.  Given  the  mission  criticality  and  software¬ 
intensive  architectures  of  present  weapon  systems,  slight  changes  in  COTS  products  are 
simply  unacceptable.  Minor  changes  to  a  piece  of  COTS  hardware  can  have  serious 
implications  to  readiness  and  program  costs,  given  their  software  intensive  nature.  It 
typically  takes  a  significant  effort,  in  tenns  of  time  and  money,  to  develop,  test  and 
deploy  upgraded  changes.  To  further,  complicate  the  issue,  these  weapon  systems  are 
developed  and  deployed  in  small  quantities  making  them  unattractive  for  typical 
commercial  business  interest.  The  uniqueness  of  these  systems  makes  them  difficult  to 
support  affordably.  Given  that  commercial  technology  refresh  cycles  are  around  18-24 
months  where  the  DoD  can  barely  hope  to  refresh  every  5-7  years,  there  is  little  incentive 
for  major  equipment  manufacturers  to  continue  production  of  a  product  that  no  longer 
fulfills  their  business  objectives  just  for  the  sake  of  accommodating  the  military,  which 
makes  up  less  than  0.4%  of  the  market.  There  is  really  only  one  of  two  ways  to  handle 
this  dilemma.  Either  accelerate  the  acquisition  phase,  which  is  highly  unlikely  given  the 
conservative  DoD  acquisition  approach,  or  extend  the  supportability  of  the  COTS 
products.  Additionally,  as  the  commercial  content  within  military  systems  increase,  the 
issue  of  COTS  product  supportability  is  complicated  by  orders  of  magnitude.  Consider 
for  a  moment  the  eventual  increase  in  technology  refreshes  needed  across  the  DoD/Navy 
program  spectrum  as  a  result  of  the  tremendous  proliferation  of  COTS  in  military 
applications.  This  increase  makes  the  issue  of  COTS  supportability  a  major  concern 
during  acquisition  and  support  strategy  development.  For  program  planning  and 
budgeting  purposes  a  mechanism  is  needed  to  effectively  assess  the  COTS  product 
supportability  position  for  a  particular  program.  To  this  end,  the  SSB  system  provides  a 
support  recommendation  process  for  each  COTS  product  in  the  weapon  system  under 
analysis.  This  approach  assists  the  program  manager  in  making  decisions  that  will 
impact  life  cycle  costs  of  the  weapon  system  while  meeting  technical  design 
requirements.  From  a  planning  and  budgeting  perspective  it  provides  higher  confidence 
in  future  program  cost  predictions.  The  output  of  the  SSB  process  helps  program 
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managers  map  proposed  technology  updates  to  system  deployment,  operation  and  support 
plans. 

3.  Impact  to  Acquisition  Strategy 

SSB  Implementation  efforts  and  the  subsequent  Business  Case  Analysis  have 
demonstrated  that  the  SSB  infrastructure  is  an  affordable  approach  for  mitigating 
program  supportability  risk  due  to  COTS  products.  The  Marketing  Plan  emphasizes  the 
collaborative  nature  of  the  SSB  process  to  leverage  the  various  areas  of  high  performance 
and  ability  residing  in  the  government,  big  business  and  the  small  businesses.  From  an 
acquisition  standpoint,  the  COTS  product  risks  are  quantifiable  and  shared  across  the 
infrastructure.  The  SSB  process  was  conceived  for,  and  therefore  sensitive  to,  the 
supportability  of  fielded  COTS  products  as  defined  by  the  warfighter.  As  an  acquisition 
strategy  it  extends  the  life  cycle  and  supportability  of  COTS  and  ensures  late-life  cycle 
supply  support.  The  SSB  process  essentially  permits  the  DoD  to  be  successful  in 
leveraging  commercial  developments  with  appropriate  economies  of  scale  in  order  to 
reach  its  military  performance  goals  while  offsetting  the  problem  of  DMSMS. 

The  SSB  infrastructure  directly  supports  existing  combat/weapon  systems.  In  this 
way  it  provides  the  Program  Office  an  additional  support  solution  alternative.  This 
alternative  can  be  implemented  early  in  the  acquisition  process  to  optimize  the  value  and 
viability  of  COTS  product  usage.  The  SSB  process  can  also  provide  insight  to  the 
supportability  of  selected  COTS  products  early  enough  in  the  acquisition  process  to 
significantly  reduce  program  risk  related  to  COTS  and  Life  Cycle  Management. 
Additionally,  when  applied  to  various  DoD/Navy  programs,  COTS  product  commonality 
could  lead  to  a  flexible,  ILS  approach.  This  scenario  would  likely  have  a  ripple  effect 
that  provides  incentives  for  the  commercial  industry  to  develop  long-term  relationships 
with  the  respective  Program  Offices. 

The  essence  of  the  SSB  process  lies  in  its  ability  to  detect  potential  supportability 
problems.  By  extending  the  supportability,  it  provides  sufficient  time  for  analysis  of 
alternatives  and  solutions  in  the  decision-making  processes.  Furthermore,  accurate 
assessment  of  COTS  supportability  can  be  accomplished  at  any  level  (subsystem, 
equipment,  component,  or  piece  part).  This  approach  not  only  extends  supportability  but 
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reparability  as  well.  The  SSB  approach  is  to  procure  assemblies  when  the  customer 
requires  them.  To  this  end,  the  SSB  process  is  committed  to  continual  assessment  over 
the  entire  COTS  product  life  cycle.  Again,  this  approach  breeds  a  more  informed 
decision-making  process  translating  to  improved  support  performance  and  lower  life 
cycle  costs. 

Overall,  the  SSB  process  becomes  an  additional  and  likely  the  preferred  support 
solution  alternative  for  PMs  who  will  welcome  the  schedule  flexibility  provided  by  the 
SSB  process.  The  flexibility  comes  from  the  fact  that  the  SSB  infrastructure  can  tailor 
the  support  options  in  terms  of  functions  and  expectations  demanded  by  the  warfighter. 
These  functions  include  immediate  supportability  and  fast,  reliable  and  direct  delivery  to 
the  warfighter.  The  COTS  product  supportability  assessments  are  critical  to  effective 
SSB  implementation  and  therefore  a  great  deal  of  emphasis  is  placed  on  the  collection, 
maintenance  and  dissemination  of  the  information  and  knowledge  derived. 

B.  RECOMMENDATIONS 

DoD  has  recognized  that  product  support  solutions  can  be  more  effectively 
designed  and  implemented  if  the  acquisition  and  logistics  communities  work  in 
partnership.  Within  the  SSB  infrastructure,  integrated  acquisition  and  logistics  functions 
conduct  supportability  analysis  as  an  integral  element  of  the  systems  engineering  process. 
This  process  (SSB)  should  occur  at  the  beginning  of  program  initiation  to  ensure 
designed  in  reliability  and  maintainability  throughout  the  program  life  cycle.  This  will 
also  to  ensure  that  the  system  perfonnance  baseline  remains  unchanged  therefore 
continuing  to  meet  the  warfighter’s  supportability  requirements.  Although  applicable  at 
any  phase  of  the  acquisition  cycle,  it  is  critical  to  consider  the  SSB  implementation  in  the 
earliest  possible  stage  to  gain  maximum  benefit.  Consider  the  SSB  Only  support  scenario 
developed  in  Appendix  C  (The  Business  Case  Analysis).  This  scenario  essentially 
employs  the  SSB  method  for  all  COTS  products.  The  SSB  Only  method  illustrates  a 
situation  where  SSB  was  implemented  prior  to  other  support  method  choices  and 
subsequent  commitments.  In  this  case  we  saw  the  greatest  stability  in  the  funding  profile 
and  the  lowest  initial  investment  amount.  Together  they  result  in  the  lowest  risk  to  the 
program  while  providing  more  flexibility  and  sustainment  capability. 
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The  SSB  process  should  be  a  continuous  process.  COTS  product  supportability 
assessments  should  be  repeated  frequently  throughout  the  acquisition  cycle.  This 
approach  not  only  keeps  the  data  stored  on  COTS  products  fresh,  but  also  allows  for 
some  maturation  of  the  process.  The  idea  is  a  continuous  improvement  environment  that 
will  ensure  that  the  most  cost-effective  methods  of  support  are  being  considered  and 
subsequently  offered  to  the  PMOs. 

The  program  manager  is  expected  per  DoDD  5000  to  use  the  most  effective 
source  of  support  that  optimizes  performance  and  lowest  life  cycle  cost,  consistent  with 
military  and  statutory  requirements.  The  source  of  support  may  be  organic  or 
commercial,  but  its  primary  focus  is  to  optimize  customer  support,  achieve  maximum 
weapon  system  availability  at  the  lowest  Total  Ownership  Cost.  At  their  disposal,  the 
program  manager  has  a  set  of  support  methods  that  can  be  used  to  achieve  this  objective, 
the  SSB  process,  as  proven  in  the  Business  Case  Analysis  to  be  a  viable  and  effective 
support  method,  and  should  be  included  as  an  additional  support  solution  alternative  in 
the  solution  space 
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VI.  RECOMMENDATIONS  FOR  FUTURE  RESEARCH 


The  SSB  system  was  developed  as  a  contemporary  solution  in  addressing  the 
COTS  supportability  risks  as  used  in  the  Navy’s  combat  and  support  systems.  The 
assumptions,  which  underpin  the  system  are  relevant  today  and  may  or  may  not  be 
relevant  in  the  future.  These  assumptions  are  linked  to  many  facets  of  the  Naval  support 
structures,  such  as:  the  supply  system,  current  guidance  and  mandatory  policies,  business 
and  programmatic  infrastructures  (i.e.  PPBS,  ORDALT  scheduling,  etc.)  When  changes 
occur  in  any  of  these  support  structures  a  direct  or  indirect  impact  to  the  SSB  system  may 
occur.  Therefore  it  would  be  prudent  to  revisit  the  utility  and  viability  of  the  SSB  system 
in  its  entirety  as  a  future  research  area. 

The  SSB  system  development  process  has  matured  to  a  point  where  emergent 
properties  and  new  capabilities  are  evident  and  available  for  exploitation,  however  the 
system  development  process  stopped  short  from  optimizing  the  processes.  The  SSB 
system  is  developing  into  a  stable  process  and  producing  standard  data  sets.  We 
recommend  that  a  systems  optimization  process  be  attempted  for  future  researched  as  a 
continual  improvement  to  the  current  SSB  system  practices. 

Time  will  be  arbitrator  in  evaluating  the  adequacy  of  the  SSB  system 
development  process  and  the  products  produced  by  that  system.  Providing  that  the 
system  exists  long  enough  to  produce  an  adequate  amount  of  information  and  products,  it 
is  recommended  that  an  independent  review  and  analysis  be  accomplished  to  provide  a 
critical  review  of  the  entire  system  to  assess  the  value  proposition  as  claimed  by  the 
system  provides  the  Navy  the  “best  value”  alternative  for  COTS  supportability  and  if  the 
system  could  use  some  improvement  or  if  the  system  has  outlived  its  usefulness. 

The  SSB  system  was  specifically  developed  to  address  COTS  products  that  are 
microprocessor  based  products.  Many  of  the  base  tools,  practices,  methods,  and 
algorithms  used  in  the  system  are  based  on  the  electrical  commodities  group,  which  is 
appropriate  when  addressing  the  combat  weapon  and  associated  support  systems. 
However,  other  commodity  groups  such  as  mechanical,  plastics,  chemical,  optical,  and 
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ceramics  groups  have  the  same  issues  of  obsolescence  and  DMSMS  as  does  the  electrical 
commodity.  We  recommend  that  future  research  be  done  to  evaluate  the  transportability 
of  the  SSB  system  processes,  methods,  and  approach  to  meeting  the  Navy’s  needs  in 
obsolescence  and  DMSMS  created  from  other  commodity  groups. 
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VII.  ENCLOSURES: 
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use  of  examples,  templates,  tools,  methods,  and  practices.  These  implementation  tools 
and  deliverable  products  are  illustrated  through  a  set  of  enclosures  referenced  in  the 
thesis  and  its  appendices.  Most  of  the  enclosures  are  static  examples  generated  during 
the  implementation  of  the  SSB  system  on  three  Navy  programs.  However,  other 
enclosures  are  not  static  and  are  therefore  provided  on  a  web  site  (URL: 
http://www.anavision.org/ssb.htm  )  in  the  Excel  format  to  provide  a  dynamic  model  for 
use  by  an  implementer  of  the  SSB  system. 
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APPENDIX  A:  SUNSET  SUPPLY  BASE  SYSTEMS 
ARCHITECTURE 


(This  addendum  was  prepared  originally  for  the  purpose  described  below  and  required 
only  minor  adjustments  for  use  in  support  of  this  thesis.) 


PD-21  Systems  Architecture  Tenn  Project 
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ABSTRACT 


Acquisition  refonn  and  the  policies  that  it  invoked  brought  about  the 
implementation  of  COTS.  In  analyzing  the  current  situation,  this  paper  reviews  why  the 
use  of  COTS  was  implemented,  what  the  expected  positive  outcome  was,  how  COTS  fits 
into  our  national  defense  strategy,  and  what  obstacles  they  pose  in  the  context  of 
warfighter  supportability.  Technology  advances  pose  greater  problems  to  Navy 
procurements  than  for  consumer  products.  Components,  sub-systems,  and  systems 
developed  for  the  military  have  far  longer  lifecycles  than  their  commercial  and  consumer 
equivalents.  This  paper  provides  a  potential  architectural  solution  to  the  obsolescence 
issues  involving  Commercial  Off  The  Shelf  (COTS)  equipment  and  Diminishing 
Manufacturing  Sources  and  Material  Shortages  (DMSMS).  The  focus  of  this  paper  is  for 
Navy  implementation  of  the  Sunset  Supply  Base  (SSB)  architecture.  The  SSB  supplier  is 
envisioned  to  come  from  the  smaller  suppliers  who,  over  the  last  three  decades,  have 
provided  the  DoD/government  with  high  technology  in  custom  products.  Their  role  in 
this  architecture  will  allow  the  DoD  to  extend  the  life  cycle  and  supportability  of  COTS 
products  and  ensure  a  late-life  cycle  supply  source.  In  so  doing  the  SSB  permits  the  DoD 
to  be  successful  in  leveraging  commercial  developments  with  appropriate  economies  of 
scale  in  order  to  reach  its  military  performance  goals  while  offsetting  the  problem  of 
diminishing  sources  and  material.  Understanding  that  the  end  game  of  the  system  is  to 
provide  extended  supportability  of  COTS  products,  the  concept  for  this  architecture  can 
be  stated  quite  simply:  Provide  appropriate  incentives  for  the  Original  Equipment 
Manufacturer  (OEM)  to  transfer  their  intellectual  property  rights  to  an  SSB  supplier  for 
extended  production  in  support  of  the  Navy  Program  Management  Office  (PMO),  and 
collaborate  with  the  internal  Navy  resources  to  identify  and  mitigate  risk.  The 
architecture  of  the  system  is  collaborative  in  nature  and  is  defined  such  that  it  could  be 
used  by  any  DoD  entity  or  associated  allied  /  foreign  military  sales  system.  This  paper 
demonstrates  how  the  SSB  architecture  is  an  affordable  approach  for  mitigating  program 
supportability  risk  and  details  how  the  overall  purpose  is  to  provide  dependable,  cost 
effective  supportability  insurance  for  COTS  based  weapon  systems. 
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I.  INTRODUCTION 


This  paper  provides  a  potential  architectural  solution  to  the  obsolescence  issues 
involving  Commercial  Off  The  Shelf  (COTS)  equipment  and  their  associated 
Diminishing  Manufacturing  Sources,  and  Material  Shortages  (DMSMS)  risks.  In 
analyzing  the  current  situation,  we  reviewed  why  the  use  of  COTS  was  implemented, 
what  the  expected  positive  outcome  was,  and  how  COTS  fits  with  today’s  issues.  The 
DoD  design  cycle  tends  to  be  long  —  historically  10-15  years  although  today’s  goal  is  5-7 
years  [4)  McDermott]—  expensive,  and  usually  resulted  in  out-of-date  designs  by  the  time 
production  began.  COTS  products  are  driven  by  “Market  Forces”  and  world  wide 
competition,  provide  the  DoD  customer  with  several  enticing  advantages  which  were  not 
previously  available.  The  commercial  world  provides  a  quick  response  to  changing 
needs,  applications,  and  technology,  while  at  the  same  time  paying  for  development  costs 
as  part  of  doing  business.  COTS  therefore  provided  DoD  with  a  way  to  keep  up  with 
technology  using  the  cost  effective  methods  of  large  commercial  entities  (i.e.,  economies 
of  scale,  volume  rate  production,  etc.)  and  implementing  these  new  technologies  in  a 
timely  manner.  The  flip  side  to  the  positive  attributes  is  the  fact  that  even  slight  changes 
to  COTS  hardware/software  can  adversely  affect  interfaces  to  other  equipment.  Fleet 
support  for  fielded  systems  raises  problems  in  configuration  control,  and  hardware  and 
software  compatibility.  The  associated  ripple  effects  at  the  system  level  are  major  risks 
in  maintaining  Fleet  capability  and  readiness. 

There  are  many  different  strategies  that  could  be  used  to  solve  availability 
problems,  thus  ensuring  Fleet  readiness.  Which  one  makes  the  most  sense  depends  upon 
a  variety  of  factors.  These  factors  are  the  results  of  the  obsolescence  risk  health  analysis, 
the  plans  and  desires  and  schedule  of  the  customer,  engineering  analysis,  risk  analysis, 
and  a  cost  analysis  (a  cost  for  the  solution  scenarios  using  cost  models). 

The  types  of  solutions  to  choose  from  can  include  one  or  more  of  the  following: 

•  Bridge  buys 

•  Spares  utilization 

•  Maintenance  Contracts  with  Vendors 
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•  COTS/Non  Development  Items  (NDI)  replacement 

•  After-market 

A  bridge  buy  is  a  short-term  buy  solution  to  an  availability  problem.  Items  are 
purchased  to  bridge  the  time  from  some  point  before  product  obsolescence  to  a  known 
point  in  time  when  a  refresh/upgrade  is  planned.  Often  a  bridge  buy  is  perfonned  while 
the  logistics  of  the  agreed-upon  long-term  solution  become  finalized  for  execution.  In 
essence,  a  bridge  buy  should  provide  the  customer  some  time  by  solving  the  immediate 
availability  problem  for  a  period  of  six  months  to  three  years.  Bridge  buys  may  be 
desired  for  many  reasons:  1)  inability  to  accurately  assess  and  predict  the  lifetime 
demand,  2)  inabilities  to  acquire  funding  for  a  Life-of-Type  (3  to  10  year)  Buy,  (LTB) 
and  3)  a  redesign  is  the  desired  long-tenn  solution,  but  budget  constraints  may  delay  the 
effort  for  a  finite  term.  Guidelines  for  making  the  repair/replace  decision  should  be  as 
follows: 

•  If  considering  a  bridge  buy  solution,  high  price  items  should  be  investigated 
for  repair  as  opposed  to  a  bridge  buy 

•  If  considering  a  repair  concept,  bridge  buys  should  be  estimated  when  the  cost 
to  repair  is  equal  to  or  greater  than  the  cost  to  replace. 

Spares  utilization  may  be  an  option  to  support  the  equipment  until  a 
refresh/redesign  is  planned.  Typically  such  spares  come  from  supplies  maintained  from 
the  prime  contractor,  from  the  In-Service  Support  Activity,  or  from  decommissioned 
assets  tracked  by  Naval  Inventory  Control  Point  (NAVICP). 

Maintenance  contracts  with  vendors  are  utilized  to  deal  with  obsolescence  instead 
of  bridge  buying  an  item.  This  method  can  be  used  to  support  products  until  a 
technology  refresh  and/or  end  of  system  life  methods  can  be  employed.  This  concept 
allows  the  delay  of  a  technology  refresh  due  to  the  repair  capability  after  product 
obsolescence.  In  most  cases,  it  allows  the  Program  Manager  to  lower  his  support  cost 
due  to  the  cost  of  repair  being  less  than  the  replacement  costs.  This  philosophy  contains 
some  inherent  risk  associated  with  vendor's  capability  to  repair  and  the  repair  support 
period  the  vendor  is  willing  to  sign-up  for. 
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Two  approaches  can  be  taken  for  COTS/NDI  replacement.  For  a  minor  impact 
solution  approach,  it  is  possible  that  the  problem  product  is  replaced  by  a  newer  revision 
of  the  same  product  or  an  entirely  new  product  of  the  same  family.  The  major  impact 
solution  approach  consists  of  a  technology  upgrade  change  from  the  same  vendor  -  or  an 
entirely  new  product  and  vendor.  Low  complexity  and  cost  products  (Type  A)  will 
usually  fall  into  the  first  solution  approach  category  (newer  version  of  the  same  product). 
This  type  of  replacement  produces  a  minimum  impact  on  the  system.  Moderate 
complexity  and  cost  products  (Type  B)  can  cause  a  minimal  impact  and  need  to  be 
investigated  on  a  case  per  case  basis.  Both  A  and  B  types  require  an  Engineering  Change 
Proposal  (ECP)  Type  II;  however,  the  additional  costs  incurred  by  the  ECP  process 
should  be  taken  into  account.  High  cost  and  complexity  products  (Type  C)  will  usually 
cause  a  major  impact,  requiring  a  class  I  ECP  with  associated  processes,  approvals,  and 
costs.  The  program  has  the  associated  risk  of  impacting  the  interoperability  of  the  system 
using  either  solution. 

The  after  market  approach,  referred  to  in  this  paper  as  the  Sunset  Supply  Base 
(SSB),  extends  the  supportability  of  COTS  products  and  items  of  material  shortage 
predicated  on  the  needs  of  the  Navy  programs.  The  SSB  is  an  extension  of  product 
availability,  beyond  the  Original  Equipment  Manufacturer  (OEM)  assigned  date  to  drop 
the  products  as  obsolete  items.  This  approach  provides  stability  to  the  system  baseline 
configuration  over  a  defined  period  of  time  between  scheduled  Technical  Refresh/ 
Insertion  points.  The  goal  of  the  SSB  architecture  is  to  define  an  arrangement  where  the 
Navy  leverages  large  businesses  in  their  strong  suit  of  technology,  market  leader,  and 
quantity  in  manufacturing,  and  utilize  the  small  businesses  for  their  strong  suit,  namely: 
agility,  small  run  production,  and  long  term  partnership.  To  bridge  the  gap  between  the 
commercial  world’s  OEM  business  planning  and  the  Navy’s  need  for  long  tenn  support, 
a  third  party  is  brought  in:  the  Sunset  Supplier.  The  Sunset  Supplier  is  usually  a  small 
business  unit.  The  Sunset  Supplier  establishes  a  contractual  relationship  with  the  OEM  to 
produce  the  obsolete  products  for  the  OEM  customer  base,  in  this  case  the  Navy  and  it’s 
associated  contractors.  The  OEM  transfers  the  intellectual  property  and  assembly 
expertise  to  the  Sunset  Supplier,  and  for  this,  the  OEM  receives  royalty  on  the  sale  of  all 
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products  produced.  Internal  to  the  Navy  are  support  infrastructures  to  ensure 
supportability  of  Sunset  products  by  mitigating  any  component  part  obsolescence  or 
shortages  issues  if  they  exist  on  those  products.  The  infrastructure  and  support  of  the 
SSB  process  yields  not  only  significant  cost  savings,  but  also  provides  other  benefits, 
such  as: 

•  Supportability  of  products  defined  by  customer  needs  over  5,  10,  15,  or  20 
years. 

•  Life  Cycle  cost  savings,  due  to  no  lifetime  buy  at  the  assembly  level  is 
needed,  so  the  assemblies  are  procured,  as  the  customer  requires  them. 

•  Reparability  of  assemblies  over  the  designated  Life  Cycle  (5,  10,  15,  20 
years). 

•  Hardware/Software/Firmware  stability  between  Technology  Refresh/Insertion 
Cycles. 

•  Significant  reduction  in  Program  risk  as  related  to  COTS  and  life  cycle 
management. 

•  Improved  schedule  flexibility  and  support  options  that  can  be  tailored  for 
Fleet  needs. 

•  Minimal  or  no  impact  on  system  operational  performance  and  the  user.  The 
performance  will  remain  constant  using  exactly  the  same  part:  form,  fit,  and 
function  replacement,  which  have  been  made  by  the  alternate  manufacturer, 
the  Sunset  Supplier. 

The  proposed  COTS  SSB  system  provides  an  opportunity  for  a  triple  win 
situation  involving  all  entities.  The  COTS  OEM  wins  because  they  can  claim  long-term 
life-cycle  support  of  fielded  products  at  lower  costs  and  less  impact  during 
implementation  on  current  and  future  systems.  The  OEM  may  also  ask  for 
compensation/royalties  for  each  item  sold.  The  COTS  Sunset  Supplier  wins  in  terms  of 
new  customers,  new  product  lines,  and  building  long-term  relationships  with  the  user 
community.  The  Navy  wins  by  obtaining  long-term  supportability,  maintainability  and 
operational  readiness.  Program  Management  (PM)  can  optimize  upgrades,  re-designs, 
technology  refresh  intervals,  etc.  Program  management  can  also  help  expose  piece  part 
obsolescence  problems  and  shortages  before  they  affect  the  COTS  Sunset  Supplier 
through  the  use  of  a  qualified  independent  third  party  manager  and  COTS  cross- 
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functional  technical  support  team.  Defining  the  role  of  the  DoD  community  will  be 
critical  in  assuring  the  long-term  objectives  in  Fleet  operational  support. 
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II.  SYSTEMS  ARCHITECTURE  ANALYSIS 


A.  NEED 

Acquisition  Reform  and  the  policies  that  it  invoked  brought  about  the 
implementation  of  COTS.  Those  policies  encouraged  the  avoidance  of  unique 
requirements,  restrictive  statements  of  need,  and  detailed  specifications.  Together  with 
DoD  5000.2  and  the  Federal  Acquisition  Regulations,  DoD  hoped  to  leverage  the  large 
businesses  in  terms  of  state-of-the-art  technologies  and  quantity  of  manufacturing  in 
order  to  provide  state-of-the-art  technology  at  lower  costs.  COTS  technologies  are  driven 
by  industry,  and  the  COTS  manufacturers  are  driven  by  their  customer  base  of  which  the 
DoD  only  makes  up  approximately  0.4%. [1)  Glum,  2)  Robinson,  3)  Hartshorn]  To  hold  a 
place  in  their  market,  COTS  manufacturers  must  remaine  competitive,  which  means  a 
continual  push  in  the  development  and  use  of  technology.  It  is  this  intense  competition 
that  drives  the  fast  technical  update  cycles  and  ultimately  influences  technology  change 
and  direction.  To  this  end,  the  COTS  manufacturer's  position  in  the  marketplace  is 
dependent  on  the  company  size  and  its  technology  edge.  These  factors  impact  the 
direction  and  update  cycles  of  technology  and  the  products  that  employ  them.  Therefore 
the  COTS  manufacturers  hold  a  significant  place  in  weapon  system  development  and 
manufacturing  because  they  can  effectively  facilitate  the  quick  response  to  DoD  changing 
needs. 

Typically  the  DoD  design  and  develop  cycles  span  5  to  7  years  (10-15  years 
historically)[4)  McDermott]  and  are  expensive  and  often  deploy  out  of  date  equipment. 
COTS  manufacturers  on  the  other  hand  take  a  big  business  approach  in  offsetting 
development  costs  through  economies  of  scale  and  volume  rate  productions.  Therefore, 
they  can  effectively  implement  technology  change  in  a  much  timelier  manner.  Through 
the  Acquisition  Reform  Initiatives,  DoD  is  encouraged  to  capitalize  on  these  big  business 
characteristics  and  allow  industry  to  be  burdened  with  the  technology  development  costs. 
The  expected  result  for  the  DoD  is  lower  overall  developmental  investments  and  an 
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opportunity  to  be  able  to  synchronize  their  design  efforts  with  state-of-the-art 
technologies. 

The  widespread  use  of  COTS  in  military  weapon  systems  does  however  bring 
certain  challenges.  Nothing  is  as  easy  as  it  looks.  There  are  serious  obsolescence  issues 
associated  with  the  use  of  COTS,  as  well  as  other  material  shortages  issue.  The  challenge 
is  to  provide  life  cycle  support  of  fielded  systems  that  use  COTS  products  as  part  of  the 
system’s  critical  components.  The  life  cycle  for  some  military  weapon  systems  may 
exceed  20  or  30  years.  This  is  not  at  all  consistent  with  big  business  timelines,  and  there 
is  presently  no  incentive  for  COTS  manufacturers  to  continue  production  of  DoD  COTS 
products  on  a  small  scale.  The  driving  force  here  is  the  market  driven  rate  of  technology 
change  in  the  commercial  world.  In  the  commercial  world  technology  updates  occur  over 
an  18-month  to  2  year  cycle.  [1)  Glum,  2)  Robinson,  4)  McDermott]  By  contrast,  the 
DoD  experiences  technology  refresh  cycles  between  5  and  7  years.  [  4)  McDermott]  This 
cycle  is  impacted  not  only  by  software  and  hardware  updates  but  by  programmatic 
schedule  changes  as  well.  The  challenge  is  further  exacerbated  by  how  the  military  will 
continue  to  develop  weapon  systems  that  do  not  fall  prey  to  technology  that  will  not  last 
or  technology  that  will  undergo  significant  change. 

Technology  changes  will  occur  in  the  COTS  arena  and  will  have  direct  impacts 
on  military  weapon  systems  existing  and  even  those  under  development.  Slight  changes 
in  software  could  have  devastating  effects.  Quite  often  systems  are  built  around  software 
which  means  systems  architectures  are  dictated  by  software  and  slight  software  changes 
will  likely  have  significant  cost  impacts.  Relatively  small  software  changes  could  have 
very  expensive  consequences.  To  expound  on  the  implication  of  software  change 
impacts,  we  need  to  understand  that  software  may  not  only  dictate  certain  standards,  but 
that  software  changes  occur  fairly  regularly  in  the  commercial  world  and  re-integration  is 
difficult  and  expensive.  The  DoD  has  to  be  aware  of  the  impacts  to  hardware  due  to 
software  changes.  Likewise,  slight  changes  in  COTS  hardware  may  impact  software 
applications.  Additionally,  there  could  likely  be  impacts  in  tenns  of  interfaces  with  other 
equipment  or  systems  that  may  not  be  so  apparent.  Subtle  specification  changes  to  COTS 
hardware  (i.e.  timing,  execution...)  could  have  devastating  ripple  effects.  These  negative 
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effects  will  be  at  the  system  level  and  will  substantially  increase  the  risks  associated  with 
using  COTS  in  the  future. 

Since  military  weapon  systems  are  typically  unique,  the  use  of  COTS  becomes  a 
tricky  business  in  terms  of  dictating  system  design  and  ultimately  life  cycle  support.  In 
terms  of  software,  military  applications  tend  to  be  very  specific,  and  the  weapon  system 
cannot  tolerate  or  support  changes.  Compatibility  and  configuration-control  become 
crucial  elements  for  both  software  and  hardware.  Support  activities  are  pressured  to 
maintain  stabilized  baselines  in  order  to  keep  the  certification  of  the  system  verifiable. 
These  include  not  only  the  initial  integration  site  but  also  the  interoperability  of  fielded 
systems  subsequent  to  changes  (i.e.  installation  of  replacement  parts,  firmware,  software 
or  hardware  revisions,  etc. . .). 

To  fully  understand  this  issue  of  support,  we  must  revisit  certain  DoD 
characteristics.  Military  acquisition  is  characterized  by  high  development  costs  and  very 
long  development  cycles;  therefore  military  procurements  are  forced  to  project  future 
needs  and  purchase  as  many  products  or  components  as  they  think  they  will  need. 
Furthermore,  in  light  of  unique  military  applications,  the  lengthy  life  cycles  and  the  5  to  7 
year  technology  refresh  rate,  the  DoD  realizes  that  they  presently  have  no  control  over 
product  evolution,  and  therefore  must  compensate  by  staying  aware  of  pending  changes. 
This  is  critical  if  the  military  is  to  expect  any  appreciable  success  in  support  of  their 
weapon  systems.  Operational  and  maintainability  support  is  expected  over  the  entire  life 
cycle  of  the  system.  This  includes  support  for  design  and  development  efforts  as  well. 
As  mentioned  previously,  DoD  design  and  development  cycles  spanning  10  to  15  years, 
are  expensive  and  often  deploy  out  of  date  equipment.  These  design  and  development 
activities  must  rely  on  commercial  products  to  be  available  when  the  design  goes  into 
production.  Furthermore,  production  and  manufacturing  facilities  must  rely  on  the  source 
of  supply  in  producing  the  systems  they  were  contracted  for,  which  will  include 
commercial  products  that  contain  their  own  supportability  issues. 

The  impacts  of  ineffectiveness  to  support  our  weapon  systems  throughout  their 
life  cycle  will  be  realized  in  military  readiness  and  capability.  When  we  consider  the 
huge  investments  that  DoD  makes  in  getting  technology  to  the  warfighter  and  training 
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our  warfighter,  support  of  our  weapon  systems  should  not  be  the  weak  link  in 
maintaining  high  levels  of  combat  readiness  and  personnel  safety.  This  weak  link  might 
be  the  result  of  the  ever-increasing  pressure  to  reduce  costs.  Very  often  we  hear  of  cost 
as  the  independent  variable  in  design  and  development  efforts  and  that  total  ownership 
costs  should  be  factored  into  the  design  process.  To  do  this  the  design  activities  must 
maintain  a  holistic  perspective  of  the  system  to  include  life  cycle  support  of  technologies 
that  have  been  selected  for  insertion  into  their  weapon  systems. [5)  Osmundson]  With  the 
challenge  of  reducing  costs  and  effectively  supporting  the  warfighter,  today's  systems 
architects  for  DoD  systems  must  understand  what  drives  cost  in  order  to  carefully 
consider  alternatives  for  life  cycle  support. 

The  cost  associated  with  supporting  weapon  systems  throughout  their  life  cycle  is 
perhaps  most  sensitive  to  the  availability  of  components  that  are  needed  to  maintain 
stability  in  the  operational  context.  As  legacy  systems  age,  their  associated  support  and 
maintenance  costs  rise  dramatically  due  to  obsolescence,  reliability  and  supportability 
problems  while  at  the  same  time  the  performance  of  the  system  decreases.  As  original 
equipment  manufacturers  synchronize  their  product  lines  with  technology,  products 
presently  deployed  in  DoD  weapon  systems,  as  well  as  products  intended  for  use  in 
developmental  systems,  will  be  affected.  Alternate  components  or  parts  will  need  to  be 
considered  for  acceptance  or  rejection.  There  will  be  material  shortages  occurring 
because  of  the  social,  economic,  and  political  environments.  In  either  case  there  will  be 
costs  associated  with  these  decisions  and  cost  must  be  managed  effectively.  If  the 
alternate  part  is  accepted,  an  engineering  change  proposal  will  need  to  be  initiated.  There 
is  cost  associated  with  preparation,  coordination,  scheduling  and  testing  of  the  alternate 
part.  If  the  alternate  part  is  unacceptable,  large  product  buys  will  be  needed  to  ensure 
operational  integrity  and  support  of  the  system  over  its  life  cycle.  There  is  cost  with 
developing  a  new  source  of  supply.  In  these  cases  there  are  issues  of  where  to  buy,  how 
much  to  buy,  where  to  stock  them,  and  how  to  manage  the  costs  and  logistical  support  to 
meet  the  needs  of  the  customer. 

Understanding  costs  will  help  government  activities  meet  the  needs  and  desires  of 
the  customer,  mainly  in  assuring  life  cycle  support  of  COTS.  More  specifically,  we  need 
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to  extend  the  supportability  of  COTS  since  we  know  that  the  life  cycle  of  many  weapon 
systems  exceed  the  life  expectancy  of  the  COTS  used.  By  addressing  the  supportability 
issue  we  effectively  address  a  much  deeper  need,  that  is  warfighter  readiness  and 
capability.  By  assuring  COTS  supportability  through  the  system’s  life  cycle  we  can 
consequently  ensure  reasonable  combat  readiness  and  capability  status.  In  essence  we 
need  to  provide  stability  in  terms  of  baseline  configuration  of  the  weapon  systems  that 
use  COTS  in  order  to  support  the  periods  of  time  between  technology  refresh  cycles. 
That  is  to  say  there  is  a  compelling  need  to  improve  the  supportability  of  fielded  products 
for  the  period  necessary  to  meet  the  user  requirements.  In  satisfying  this,  it  must  be  cost 
effective  at  the  initial  procurement,  over  the  life  cycle  of  the  system,  and  ultimately 
provide  the  lowest  possible  impact  to  Total  Ownership  Cost  (TOC).  This  will  involve  a 
predictable  and  sustainable  process  for  support  of  fielded  and  developmental  systems.  To 
be  successful,  this  process  will  need  to  adequately  identify  risk,  mitigate  those  risks,  and 
provide  resolution  methods  and  planning.  Knowing  now  that  a  new  architecture  is 
needed  to  meet  these  needs  we  must  conclude  that  a  departure  from  traditional  methods  is 
necessary  to  meet  the  challenge  of  sound  planning  and  careful  tailoring  of  COTS 
acquisition  at  the  lowest  possible  cost. 

Reduced  government  funding  and  manpower  levels  have  further  emphasized  the 
need  to  improve  life  cycle  management  processes.  Perhaps  the  focal  point  for  this  effort 
is  COTS  risk  mitigation  during  development  and  for  fielded  weapon  systems.  This  type 
of  continual  assessment  is  needed  to  offset  the  fast  technology  update  cycle  experienced 
in  the  commercial  realm.  This  will  provide  system  baseline  configuration  stability  and 
supportability.  Key  to  this  is  the  need  to  continually  assess  original  equipment 
manufacturers.  This  assessment  should  provide  valuable  insight  to  the  vendor's  stability, 
which  in  turn  impacts  the  level  of  risk  associated  with  specific  components  employed  by 
the  DoD.  Such  assessments  would  perhaps  look  at  how  limited  a  vendor's  product  line  is 
and/or  make  judgments  on  the  potential  of  specific  products  in  that  line  to  change  or 
disappear.  To  this  end,  it  becomes  important  to  determine  the  likelihood  that  a  vendor 
will  continue  to  provide  DoD  assets  and  the  consistency  of  that  product  line.  The 
challenge  is  in  the  architecting  of  a  process  that  is  proactive,  disciplined  and  systematic, 
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and  will  consider  and  address  the  needs  as  discussed  here  for  the  intended  audience.  The 
audience  being  those  customers  or  stakeholders  whose  needs  must  be  fulfilled. 

The  customer  in  this  case  takes  on  many  dimensions. 

The  End  User  -  Certainly  the  end  user  must  be  considered  for  it  is  the  end  user  we 
depend  on  to  operate  our  weapon  systems  and  provide  the  expected  defense  as  defined  in 
our  national  strategic  policies. 

The  Program  Management  Offices  (PMO)  -  This  includes  the  initial  acquisition 
community  whose  purpose  is  the  acquisition  of  new  systems.  They  also  support  the  in- 
service  engineering  activities  that  must  continue  to  procure  parts  as  part  of  an  alteration 
kit  or  on-going  support  for  the  warfighter,  including  repair  and  replacements  of  parts. 
They  support  the  integrated  logistical  support  functions,  which  must  plan  the  long-term 
support  of  fielded  equipment  and  must  support  equipment  between  changes  to  the 
equipment  base  line.  One  of  the  PMO’s  primary  responsibilities  is  budgetary  support  for 
personnel  who  must  project  the  availability  of  products  that  extend  over  the  2-year 
Program  Objective  Memorandum  (POM)  cycle  and  the  3-5  year  implementation  cycle. 
Additionally  they  must  fund  support  military  field  activities  or  service  contractors  who 
prepare  Cost,  Health,  and  Risk  models  which  quantify  the  availability  and  supportability 
of  the  fielded  systems. 

Interoperability  Support  Activities  -  These  activities  must  obtain  and  maintain  a 
stabilized  baseline  in  order  to  keep  the  certification  of  the  system  verifiable.  These 
support  activities  include  not  only  the  initial  integration  site  but  also  the  interoperability 
of  fielded  systems  subsequent  to  changes  (i.e.  installation  of  replacement  parts,  firmware, 
software  or  hardware  revisions,  etc.). 

Design  and  Development  Activities  -  These  activities  must  rely  on  commercial 
products  to  be  available  when  the  design  goes  into  production. 

Production/Manufacturing  F acilities  -  These  facilities  must  rely  on  the  source  of 
supply  in  producing  the  systems  they  were  contracted  for,  which  will  include  commercial 
products  that  contain  supportability  issues. 
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B.  PURPOSE 


The  overall  purpose  of  the  SSB  system  is  to  provide  dependable,  cost  effective 
supportability  insurance  for  COTS  based  weapon  systems.  The  result  will  provide  a 
solution  to  COTS  obsolescence  issues,  material  shortages  issues,  and  extend  the 
supportability  of  COTS  components.  The  architecture  should  address  COTS  technology 
obsolescence  management  through  product  and  technology  obsolescence  forecasting 
methodologies  and  provide  a  new  process  for  managing  changes  with  COTS  based 
systems.  The  final  architecture  should  respond  to  the  voice  of  the  customer,  who  is 
demanding  credible  combat  power  through  design  and  supportability,  by  putting  speed 
and  agility  into  the  process,  and  ultimately  provide  some  value  as  perceived  by  the 
customers. 

C.  GOALS 

1.  Expectations 

Understanding  the  needs  of  the  customers  we  must  now  derive  specific  goals  to 
meet  those  needs.  In  establishing  these  goals  we  must  also  relate  them  to  our  national 
defense  strategy  and  acquisition  policies.  Therefore  we  understand  the  necessity  for 
effective  collaboration  between  the  warfighter,  the  program  offices,  and  private  industry. 
To  this  end,  we  expect  the  architectural  form  of  such  a  process  will  exhibit  the 
characteristics  of  a  collaborative  system,  which  necessitates  voluntary  participation. 
Figure  1  depicts  a  conceptual  illustration  of  such  a  collaborative  system  within  the  Navy 
for  the  Sunset  Supply  Base.  This  voluntary  participation  is  needed  for  the  assemblage 
and  maintenance  of  such  a  system  and  is  crucial  to  its  success.  Success  will  be  measured 
continuously  for  those  properties  that  emerge,  against  how  well  they  fulfill  the  purpose 
and  how  well  they  are  managed  to  accomplish  their  specified  tasks.  Through  abstraction 
we  can  visualize  a  system  that  has  very  distinct  elements  that  work  together  for  mutual 
gain  and  to  satisfy  a  common  need.  Therefore,  we  can  expect  that  such  a  system  should 
evolve  from  existing  capabilities  or  systems.  A  complex  system  will  develop  and  evolve 
within  an  overall  architecture  much  more  rapidly  if  there  are  stable  intermediate 
forms.  [6)  Maier-Rechtin]  Therefore,  we  can  expect  a  period  of  time  when 
experimentation  is  performed  during  which  collaborative  requirements  are  identified  and 
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refined,  and  systems  modified  and/or  interfaces  developed  to  allow  the  required 
collaboration.  By  allowing  the  system  to  develop  using  such  an  evolutionary  method  we 
are  taking,  what  some  consider  a  spiral  approach  to  system  maturation,  we  can  eliminate 
the  need  for  development  of  high-level  coordination,  thus  streamlining  the  process  and 
insuring  that  the  system  fits  the  problem  appropriately.  This  streamlining  should  provide 
stable  intermediate  forms  that  will  be  self-supportive  technically,  economically,  and 
politically.  By  taking  this  approach  all  participants  should  derive  some  benefit  that  will 
foster  long-term  relationships. 


Concept  Generation  for  Sunset  Supply  Base 


Appendix  A  Figure  1:  Concept  Generation  for  Sunset  Supply  Base 
2.  Objectives 

The  DoD  is  looking  to  improve  program  supportability  and  extend  COTS 
reparability  for  5-7  years  and  beyond.  They  would  like  the  ability  to  match  COTS  update 
cycles  with  program's  technical  roadmap/refresh  efforts.  To  do  this  they  will  need  insight 
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to  potential  obsolescence  issues  through  predictive  tools  and  be  able  to  mitigate 
maintenance  and  supportability  issues  at  the  assembly  level. 

The  COTS  manufacturer  needs  to  be  aware  of  the  enhanced  product 
supportability  benefits  that  will  mean  continued  profits  for  their  stakeholders.  Their 
willingness  to  develop  long-term  relationships  with  the  DoD  is  paramount  for  success. 
The  DoD  must  encourage  such  teaming  and  still  be  able  to  offer  protection  for  the  COTS 
manufacturers'  proprietary  design  rights. 

One  of  the  main  objectives  in  developing  such  long-term  relationships  is  to  clarify 
the  roles  of  all  participants  in  the  process.  By  doing  this  we  need  to  establish  specific 
interfaces,  and  these  interfaces  will  have  to  be  effectively  managed  to  achieve  efficiency 
and  success.  The  greatest  dangers  are  at  the  interfaces. [5)  Osmundson,  6)  Maier-Rechtin] 
Therefore  we  must  pay  close  attention  to  the  interfaces  and  understand  why  each  entity 
participates  and  continue  to  provide  incentives  for  continued  involvement. 

3.  Specific  Goals 

The  systems  architecture  shall  have  the  following  goals: 

a)  To  Be  Able  to  Identify,  Quantify,  and  Mitigate  Supportability 
Risk  to  Programs. 

This  process  must  be  affordable  and  be  able  to  successfully  assess  the  cost 
savings  attributed  to  the  process.  The  infonnation  derived  from  identification  and 
mitigation  of  supportability  risk  shall  be  quantifiable  and  readily  accessible  by 
participants. 

b)  Extend  the  Life  Cycle  and  Supportability  of  COTS. 

Supportability  of  fielded  hardware  shall  be  defined  by  the  warfighter.  The 
process  shall  take  this  into  account  as  it  defines  the  metrics  for  assuring  late-life  cycle 
supply  source.  To  be  successful  the  DoD  shall  continue  to  leverage  commercial 
developments  with  appropriate  economies  of  scale  in  order  to  reach  expected  military 
performance  goals  and  still  offset  the  problem  of  diminishing  material. 
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c)  Provide  Infrastructure  to  Support  Existing  Platform/Combat 
Systems  in  Support  of  the  Program  Office. 

This  goal  is  to  provide  infrastructure  earlier  in  the  development  process  to 
demonstrate  and  prove  COTS  components  and  to  support  existing  weapon  systems.  This 
will  provide  significant  reduction  in  program  risk  as  related  to  COTS  and  life  cycle 
management. 


d)  Achieve  Significant  and  Quantifiable  Cost  Savings  over  the 
Product  Life  Cycle. 

Cost  structures  shall  be  tracked  and  continually  assessed  over  the  entire 
product  life  cycle.  This  will  significantly  impact  the  effectiveness  of  informed  decision¬ 
making  that  is  needed  for  success.  The  up  front  cost  assessments  will  contribute  to  the 
life  cycle  cost  savings,  due  to  NO  lifetime  buys  at  the  assembly  level.  The  assemblies 
would  be  procured,  as  the  customer  requires  them. 

e)  A  Reliable,  Affordable,  Repeatable,  and  Expandable  Process  that 
meets  the  Customer’s  Performance  Expectations  (e.g., 
Accessible,  Transportable,  Maintainable,  Predictable). 

The  process  shall  have  definable  and  repeatable  characteristics  in  order  to 
provide  a  comprehensive  and  flexible  solution  to  supporting  fielded  hardware.  It  shall 
provide  an  independent  utility  (an  alternative  option  for  DMSMS/Obsolescence 
Management)  for  programs  when  implementing  COTS  products  and  whose  solutions  will 
have  minimal  or  no  impact  on  system  operational  performance. 

f)  Institutionalize  Methods  for  Proactive  Management  of  COTS 
Including  DMSMS  Issues. 

The  institutionalization  of  these  methods  will  require  the  development  of 
non-standard  Integrated  Logistics  Support  (ILS)  and  contract  strategies  and  imple¬ 
mentation  methodologies  that  will  access  the  commercial  support  base.  In  doing  this,  the 
process  must  be  sensitive  to  proprietary  design  rights  and  provide  a  forum  for  appropriate 
negotiations.  The  methods  employed  shall  improve  product  supportability  problem 
detection  and  provide  sufficient  time  for  appropriate  decision-making  processes  to 
implement  analysis  for  alternatives  and  solutions.  Overall  it  shall  provide  aid  to  the 
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decision-maker  by  providing  technology  assessment  and  management  guidance  at 
various  levels  -  piece  parts,  lowest  replaceable  units,  units,  subsystems  and  multiple 
platforms. 

g)  A  System  that  Leverages  Navy  and  Commercial  Supportability 
Assets  and  Provides  a  Networked  Solution. 

The  process  must  take  advantage  of  inherently  governmental  functions  for 
DMSMS  Management  at  the  various  field  activities  and  coordinate  with  the  commercial 
supportability  assets.  This  coordination  must  be  embraced  through  a  thoroughly  meshed 
and  maintainable  communication  network. 

h)  Leverage  across  Government  Programs  with  Extended 
Applicability  through  Contract  Strategies,  Methodologies,  and 
Incentives  to  Entice  Commercial  Industry  Participation. 

The  process  must  be  transportable  in  terms  of  its  applicability  to  various 
DoD  entities  and  their  contract  strategies.  Aggressive  integration  of  common 
components  across  DoD  entities  should  lead  to  flexible  integrated  logistical  support  of 
COTS  products  and  should  provide  incentive  for  the  commercial  industry  to  develop 
long-term  relationships. 

i)  Forecast  Budget  Requirements  in  Support  of  the  Programs/War 
Fighter/Consumer. 

The  process  shall  provide  predictive  infonnation  for  the  decision-making 
components  of  the  DoD  program  offices.  In  forecasting  budget  requirements  in  support 
of  programs/warfighter/customer  the  outputs  from  trade-offs  and  assessments  must 
achieve  a  high  level  of  confidence  to  the  program  office. 

j)  Improve  Schedule  Flexibility  and  Support  Options  of  System 
Upgrades  or  New  Development  Initiatives. 

The  process  should  incorporate  improved  schedule  flexibility  and  support 
options  that  can  be  tailored  for  the  warfighter  and  the  support  activities  needs.  One  of  the 
main  objectives  shall  be  the  compression  of  provisioning  timeframes.  To  this  end, 
increased  responsibility  on  the  contractor's  part  is  assumed  in  terms  of  stockage,  storage 
and  issue  of  COTS  spares  and  repair  parts.  The  benefits  that  we  will  strive  to  achieve 
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shall  include  immediate  supportability,  elimination  of  government  levels  of  inventory 
stock,  large  commercial  distribution  systems,  no  source  inspection,  commercial 
packaging,  fast  and  direct  delivery  to  the  warfighter,  and  warranty  of  components. 

B.  CONCEPT 

The  utility  in  the  development  of  a  concept  in  the  architecting  process  is  to  guide 
the  transformation  of  the  function  of  a  proposed  system  into  a  usable,  realizable  form.  [5) 
Osmundson]  An  understanding  of  the  customer  base  and  their  needs  identified  in 
previous  paragraphs  helps  in  molding  the  conceptual  model  as  shown  in  Figure  1. 
However,  it  does  not  enable  a  designer  to  realize  the  complete  vision.  Most  of  the 
functional  pieces  identified  in  the  conceptual  model  already  exist,  but  what  is  missing  is  a 
method  to  tie  the  independent  systems  into  an  interoperable  “Systems  of  Systems”  that 
will  yield  new  and  emergent  properties  which  are  greater  than  the  sum  of  the  independent 
systems  capabilities.  Additionally,  the  concept  for  a  new  independent  system  will  be 
developed  and  folded  into  the  “Systems  of  Systems”  concept  architecture.  This  new 
system  is  being  developed  to  meet  previously  unmet  needs  and  goals,  identified  in  the 
customer  needs  and  analysis.  The  co-development  of  these  two  entities  (i.e.,  the  new 
system  and  the  “Systems  of  Systems”)  will  be  shown  to  be  symbiotic  in  producing  the 
desired  emergent  properties.  Taking  a  holistic  view  of  the  concept  development  we  (the 
Architects)  employ  the  heuristic,  which  states  “Design  the  structure  with  good  bones”  [6) 
Maier-Rechtin]  and  from  our  vantage  point  it  means  at  least  the  minimum  collection  of 
bones  to  provide  the  new  emergent  properties. 

Core  to  the  conceptual  development  of  our  two  separate  systems  is  the  method  of 
planned  development,  which  does  not  rely  on  a  centralized  design  entity.  Instead,  the 
planned  development  of  our  systems  will  use  a  collaborative  approach  where  its 
functions,  emergent  properties  and  even  the  way  in  which  it  is  used  will  evolve  over  time. 
So,  “What  is  a  collaborative  system?”  Maier  &  Rechtin  [6)  Maier-Rechtin]  define  a 
system  as  a  collaborative  system  when  its  components  exhibit  the  following 
characteristics: 

•  Fulfill  valid  purpose  in  their  own  right,  and  continue  to  operate  to  fulfill  those 
purposes  if  disassembled  from  the  overall  system. 
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•  Are  managed  (at  least  in  part)  for  their  own  purposes  rather  than  the  purposes 
of  the  whole;  the  component  systems  are  separately  acquired  and  integrated 
but  maintain  a  continuing  operational  existence  independent  of  the 
collaborative  system. 

Examples  of  collaborative  systems  include  the  Internet,  electrical  power  systems, 
multinational  defense  systems,  joint  military  operations  and  intelligent  transportation 
systems.  Maier  &  Rechtin  [6)  Maier-Rechtin]  articulate  the  above  systems  are 
“collaborative  in  the  sense  that  they  are  assembled  and  operate  through  the  voluntary 
choices  of  the  participants,  not  through  the  dictates  of  an  individual  client.” 

The  collaborative  development  method  was  chosen  to  meet  several  of  the  needs 
and  goals  identified  through  our  analysis.  A  major  consideration  impacting  the 
developmental  approach  was  the  political  environment  with  respect  to  the  use  and 
leverage  of  Navy  assets  in  the  performance  of  inherently  governmental  functions.  The 
politics  permeate  through  all  our  systems:  from  the  top  as  “The  Corporate  Thrust,”  to  the 
local  politics  at  the  field  activities  as  “  The  Rice  Bowl  Mentality.”  In  looking  at  the  “Big 
Picture”  our  team  uses  the  following  heuristic  as  a  guiding  principal:  “If  the  politics 
don’t  fly,  the  hardware  never  will.”[5)  Osmundson]  Although  we  are  architecting 
processes  and  methods,  the  statement  holds  equally  true.  Two  heuristics  that  apply 
specifically  to  collaborative  systems  were  added  to  keep  the  concept  development  on 
track: 

•  The  emergent  capability  is  the  whole  point  of  the  system;  but  the  architect 
may  only  be  able  to  influence  the  interfaces  among  the  nearly  independent 
parts,  the  components  are  outside  the  scope  and  control  of  an  architect  of  the 
whole. [6)  Maier-Rechtin] 

•  Consider  a  collaborative  system  a  franchise.  Always  ask  why  the  franchisees 
choose  to  join,  and  choose  to  remain.  [6)  Maier-Rechtin] 

The  concept  model  (Figure  1)  illustrates  the  “System  of  Systems”  developmental 
approach,  which  focuses  primarily  on  the  interfaces  and  the  interoperability  of  the  final 
system.  The  World  Wide  Web  (WWW)  provides  the  interconnection  and  connectivity 
between  all  available  resources  offering  a  broad  scope  of  possibilities  including  Navy 
business  that  is  carried  out  in  the  public  domain.  The  Navy-Marine  Corps  Intranet 
(NMCI)  provides  another  venue  for  the  Navy  assets  to  leverage  each  other’s  resources, 
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share  sensitive  data,  and  accomplish  inherently  governmental  functions  in  a  secure 
environment.  One  very  important  point  to  be  made  regarding  collaborative  efforts 
between  the  Navy  Field  Activities,  the  Fleet,  and  other  Navy  resources  is  that  these 
efforts  are  not  based  on  a  zero  sum  end  game.  Specifically,  the  gain  of  capabilities  by 
one  field  activity  by  using  the  collaborative  system  does  not  subtract  capability  from  any 
other  field  activity,  but  rather  what  is  really  the  gain  is  due  to  the  emergent  properties  of 
the  overarching  collaborative  system.  The  word  “capability”  is  used  as  an  example,  we 
could  just  as  easily  substituted  many  other  words  such  as  funding,  core  equities,  or 
resource  allocation  and  the  logic  still  applies.  The  system  with  its  new  emergent 
properties  is  meant  to  provide  a  “Win-Win”  scenario. 

The  design  of  the  new  standalone  system  will  also  use  the  collaborative 
developmental  methods,  but  the  context  is  somewhat  different.  The  context  for  the  new 
system  is  the  incorporation  of  the  supplier  base  in  the  collaborative  environment  to 
design  into  the  system  long-term  product  supportability  as  an  emergent  property.  As  is 
apparent  in  Figure  2,  the  collaboration  environment  includes  the  following  entities: 

•  Navy  resource  manager  -  Typically  a  PMO  responsible  for  a  system  or 
systems  that  have  supportability  requirements  over  the  equipment’s  life  cycle. 

•  The  Original  Equipment  Manufacture  (OEM)  providing  state-of-the-art,  high 
volume,  short  life  cycle  (~  18  months),  Commercial-Off-The-Shelf  (COTS) 
products  used  in  the  Navy  systems. 

•  The  Sunset  Supplier  Base,  which  is  a  group  of  small,  agile,  customer- 
orientated  companies  with  a  proven  track  record  in  manufacturing 
performance  in  producing  DoD  products. 

•  The  Assessment  /  Reporting  /  Facilitating  activity  whose  primary  role  is  in  the 
development  of  the  collaborative  environment  between  all  the  entities,  using 
networking,  teaming,  and  partnering  to  stabilize  the  relationships. 
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Sunset  Supplier 


<- 


Facilitating  Activity 

Appendix  A  Figure  2:  The  COTS  Collaborative  Environment 
C.  FUNCTION  &  FORM,  A  COLLABORATIVE  SYSTEM 

1.  Overarching  System 

The  collaborative  approach  identified  in  the  “Concept”  section  provides  the 
planned  development  based  on  the  connectivity  of  existing  systems  with  the  addition  of 
another  independent  system.  In  providing  the  connectivity,  the  relationship  of  Function 
to  Form  will  identify  the  dependency  and/or  communication  paths  between  various 
entities  (Fonn)  necessary  in  accomplishment  of  the  tasks  (Function).  The  primary 
differentiating  or  emergent  property  acquired  through  use  of  the  new  “Systems  of 
Systems”  construct  is  the  leverage  gained  through  information  sharing.  The  functional 
decomposition  as  shown  in  Figure  3,  identifies  the  primary  functions  of  the  overarching 
system,  then  details  important  sub-functions  and  identifies  the  relationship  to  entities, 
which  currently  perfonn  those  functions.  Table  1  is  a  mapping  of  Function  to  Form  and 
graphically  illustrates  the  leverage  to  be  gained  through  collaborative  information  sharing 
(an  emergent  property).  Currently,  very  few  of  these  entities  are  linked  together,  and  no 
method  or  system  is  defined  to  accomplish  this  function.  This  relationship  (Table  1)  is 
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the  first  intermediate  stable  form  for  our  “Systems  of  Systems”  which  will  be  added-on 
to,  modified,  and  evolved  over  time.  The  overarching  system  once  complimented  by  the 
SSB  system  must  be  compared  to  the  initial  goals  to  access  the  adequacy  of  the 
architecture  in  meeting  the  customer  needs.  Table  2  attempts  to  do  just  that,  by 
graphically  showing  a  link  between  the  functions  designed  into  the  system  and  the  goals 
of  the  customer  described  in  Table  3. 

2.  SSB  Standalone  System 

The  planned  development  of  the  standalone  SSB  system,  as  stated  earlier,  is  a 
collaborative  architecture,  and  as  shown  in  Figure  2  consists  of  several  primary  players. 
The  Function  and  Form  of  each  of  these  entities  is  already  defined  and  all  operate  as  an 
independent  system  unto  themselves.  Each  entity  may  need  to  voluntarily  adjust  their 
functions  slightly  to  accommodate  the  collaborative  architecture,  however  most  of  the 
impacting  change  will  be  accomplished  through  the  use  of  interfaces  to  each  other  and 
the  interfaces  to  the  overarching  support  system.  The  adjustments  in  function  to  make 
the  system  obtain  its  objectives  and  purpose  are  modest,  and  the  interfaces  between  the 
entities  are  of  the  greatest  concern.  To  explain  each  player’s  accommodation  and  how 
the  interfaces  work,  we  will  look  at  the  proposed  new  system  from  the  viewpoint  of  each 
player.  Understanding  that  the  end  game  of  the  system  is  to  provide  extended 
supportability  of  COTS  products,  the  concept  can  be  stated  quite  simply:  Reward, 
through  royalties,  the  OEM  for  transferring  their  intellectual  property  rights  to  an  SSB  for 
extended  production  in  support  of  the  Navy  PMO,  and  collaborate  with  the  internal  Navy 
resources  to  identify  and  mitigate  risk. 
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Appendix  A  Figure  3:  Concept  Generation  &  Functional  Decomposition 
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Appendix  A  Table  1:  Mapping  Function  to  Form 


The  addendum  contains  the  data  dictionary  for  this  table. 
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X 

X 
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X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

Appendix  A  Table  2:  Linking  Goals  to  Functions 
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1 

Identify,  Quantify,  &  Mitigate  Supportability  Risk  to  Program 

2 

Extend  the  life  cycle  and  supportability  of  COTS 

3 

Provide  infrastructure  to  support  existing  platform/combat  systems  in  support  of 
the  Program  Office 

4 

Achieve  significant  and  quantifiable  cost  savings  over  the  product  life  cycle 

5 

A  reliable,  affordable,  repeatable,  and  expandable  process  that  meets  the 
customer’s  performance  expectations  (e.g.,  accessible,  transportable,  maintainable, 
predictable) 

6 

Institutionalize  methods  for  proactive  management  of  COTS  including  DMSMS 
issues 

7 

A  system  that  leverages  Navy  and  commercial  supportability  assets  and  provides  a 
networked  solution 

8 

Leverage  across  government  programs  with  extended  applicability  through 
contract  strategies,  methodologies,  and  incentives  to  entice  commercial  industry 
participation 

9 

Forecast  budget  requirements  in  support  of  the  programs/war  fighter/consumer 

10 

Improve  schedule  flexibility  and  support  options  of  system  upgrades  or  new 
development  initiatives 

Appendix  A  Table  3:  Goals  (Requirements) 

D.  INTERFACE  MANAGEMENT 


1.  Program  Management  Office 

Currently:  The  PMO  through  its  Integrated  Logistics  Support  (ILS)  group 
orders  COTS  assemblies  through  the  normal  support  systems  by  contract,  purchase  order, 
or  Navy  supply  system.  If  an  OEM  no  longer  supports  a  product,  then  the  Program 
Office  must  look  for  another  avenue  to  solve  the  issue,  typically  an  engineering  analysis 
and  review  is  necessary  yielding  a  variety  of  solutions  most  of  which  are  very  expensive. 
If  the  program  office  is  lucky  or  just  well  informed  (which  is  not  always  the  case),  the 
OEM  will  provide  a  notice  stating  an  “End  Of  Life”  (EOL)  date  after  which  the  OEM 
will  no  longer  support  the  specific  COTS  product.  At  this  point  the  PMO  must  make 
some  choices.  Regardless  of  the  choices  made,  the  Program  Office  incurs  a  significant 
amount  of  risk  usually  at  a  hefty  price. 

Proposed:  The  collaborative  process  is  illustrated  using  two  notional  graphics, 
Figures  4  &  5,  to  show  the  relationship  and  informational  interfaces  between  the  Program 
Office  and  the  other  identified  players.  Figure  4  shows  the  process  flow  at  a  functional 
level  delineating  the  relationship  each  player  has  to  the  others  during  the  SSB 
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development.  As  a  collaborator  in  this  process,  the  PMO  provides  the  funding  resources 
to  internal  government  activities  to  facilitate,  assess,  and  report.  Also,  the  PMO  is 
agreeing  to  pay  for  the  royalty  and  provide  the  Bill  Of  Material  (BOM).  For  their  efforts 
the  PMO  receives:  1)  an  alternate  long  term  supplier  of  the  COTS  product  and  a 
relationship  with  that  supplier  and  their  associated  OEM  that  may  be  extended  for  other 
OEM  discontinued  items,  2)  as  identified  in  Figure  5,  a  continuous  update  to  the  risk 
identification  and  mitigation  efforts,  proactively  adjudicating  obsolescence  issues 
seamlessly  on  behalf  of  the  PMO,  3)  provides  the  PMO  with  a  corporate  knowledge  data 
base  on  which  future  decisions  can  leverage,  4)  although  not  identified  through  the 
figures,  the  program  gains  reparability  and  testability  attributes  over  the  life  cycle  of  the 
system  defined  by  the  Navy’s  needs.  The  method  of  communication  being  online  is 
nearly  in  real  time  so  the  effort  expended  by  the  Program  Office  is  minimal.  Product 


ordering  is  done  using  current  procurement  methodologies. 


Appendix  A  Figure  4:  Functional  Flow  Diagram 
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Appendix  A  Figure  5:  Information/Data  Flow  Support  Structure 

2.  Original  Equipment  Manufacturer  (OEM) 

Currently:  The  OEM  is  usually  a  leading  edge  technology/design  firm  that  is 
market  driven  and  produces  at  high  volume  and  cost  reflective  of  commercial  economies 
of  scale.  The  fast  paced  environment  requires  short-lived  products  (-18-24  months)  to 
keep  up  with  the  ever-changing  technology.  The  business  case  is  just  not  there  to  cater  to 
the  DoD/govemment’s  needs  and  although  the  OEM  wishes  to  keep  this  group  of 
consumers,  the  momentum  of  the  business  cycle  keeps  the  OEM  focused  elsewhere. 
Under  these  circumstances  supportability  is  limited  to  production  run  time  (-18-24 
months)  with  approximately  a  12-month  follow-on  repair  and  test  capability  period. 

Proposed:  The  OEM  for  their  part  in  the  collaboration  effort  has  a  lot  to  gain  and 
little  to  lose.  There  is  a  business  case  to  be  made  for  making  a  profit  from  their 
intellectual  property  they  no  longer  find  useful.  The  5-15%  royalty  is  the  incentive,  but 
other  non-tangible  benefits  enhance  the  business  aspects  in  favor  of  the  collaboration 
effort.  Protection  of  their  proprietary  design  is  an  inherent  part  of  the  SSB  process 
through  “Non-Disclosure  Agreements  (NDA)”  and  contractual  mechanisms.  Important 
to  note  is  that  the  contractual  arrangements  are  made  with  another  company,  the  SSB 
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supplier,  not  the  government,  which  many  OEMs  find  favorable  since  governmental  red 
tape  would  poison  the  business  case.  This  situation  leaves  the  ownership  and  control  of 
the  commercial  products  in  the  hands  of  the  industry.  Additionally,  the  government  does 
not  have  to  pay  for  the  design  only  the  product,  a  tenet  of  Acquisition  Reform.  By 
participation  in  the  collaborative  system  the  OEM  establishes  a  long-term  relationship 
with  the  DoD/government  without  the  ongoing  supportability  issues.  In  turn  these  new 
emergent  properties  of  the  system  can  be  used  to  enhance  the  ability  of  the  OEM  to 
market  enhanced  product  supportability,  not  only  to  the  DoD/government  environment, 
but  also  any  entity,  which  is  configuration  constrained  due  to  the  business  constraints  (i.e. 
refineries,  paper  mills,  electrical  power  generation  and  control  applications,  etc.).  The 
OEM  efforts  are  concentrated  during  the  establishment  of  the  SSB  supplier  and  play  a 
crucial  part  in  assuring  that  the  OEM  reputation  will  be  in  safe  hands  when  the  SSB 
supplier  delivers  products.  The  OEM  however  does  agree  to  allow  the  internal  Navy 
resources  visibility  into  the  products  design  by  letting  the  SSB  supplier  share  the  parts  list 
complete  with  associated  component  vendor  information  along  with  a  top  level  assembly 
drawing.  This  is  information  the  government  has  not  been  privy  to  in  the  past  but  it  is 
essential  for  accomplishment  of  risk  analysis  and  yielding  the  desired  emergent 
properties  of  the  system. 

3.  SSB  Supplier 

Currently:  The  SSB  supplier  is  envisioned  to  come  from  the  large  base  of 
smaller  suppliers  who,  over  the  past  three  decades,  have  provided  the  DoD/government 
with  high  tech,  custom  products.  Using  this  supplier  base  will  reduce  the  risk  caused 
during  the  technology  transfer  process  because  of  the  proven  track  record  earned  when 
dealing  with  other  DoD/government  products.  However,  this  will  be  a  collaborative 
process  and  the  final  decision  will  reside  with  and  between  the  OEM  and  the  SSB 
supplier.  Here  the  OEM  holds  the  trump  card  and  must  be  willing  to  live  with  the  choice. 
The  small  business  SSB  supplier  typically  has  extensive  technical  know  how  in  the 
manufacturing  area  but  lacks  the  expertise  to  accomplish  proactive,  predictive 
obsolescence  management.  These  companies  are  customer  focused,  agile,  and  seek  long¬ 
term  relationships  with  their  customers. 
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Proposed:  As  for  their  part  in  the  collaboration  process,  the  SSB  supplier  must 
be  willing  to  be  contractually  bound  by  the  agreement  with  the  OEM  and  at  the  same 
time  be  willing  to  work  the  internal  government  resources  to  coordinate  and  facilitate 
supportability  efforts  while  reducing  risk  to  the  program.  Actions  required  by  the  SSB 
supplier  will  include: 

•  sharing  the  OEM  parts  list  and  drawings, 

•  be  the  purchaser,  stock  handler,  and  storage  facility  for  parts  that  have  gone 
obsolete  and  are  awaiting  consumption  once  an  assembly  order  is  placed, 

•  as  requested  by  the  program,  be  willing  to  stock  all  up  assemblies  (which  have 
already  been  paid  for)  to  enable  immediate  turnaround  times  of  fielded 
assemblies  which  have  failed, 

•  accept  all  the  responsibility  for  being  the  prime  supplier  of  the  subject 
assembly. 

In  return  for  its  efforts  the  SSB  supplier  is  rewarded  through: 

•  a  new  relationship  with  a  pre-eminent  commercial  firm, 

•  a  new  product  line, 

•  new  customers,  DoD/govemment  and  non-government, 

•  long  term  relationships  with  the  new  customers  which  enables  long  term 
business  planning, 

•  technical  partnering  with  internal  DoD/govemment  resources  not  only  for 
predictive  obsolescence  management  but  a  whole  host  of  other  specialties. 

4.  Internal  DoD/Government  Resource 

Currently:  Most,  if  not  all,  of  the  functions  identified  in  Figure  4  are  already 
accomplished  by  internal  DoD/government  resources;  however  they  are  done  in  an  ad- 
hoc  fashion  without  the  collaborative  environment,  and  with  no  defined,  supportable,  and 
repeatable  process  in  place.  The  expertise  has  always  been  available  in  the 
DoD/government  but  in  a  different  form  using  a  different  process.  Prior  to  Acquisition 
Reform,  the  MIL-Specs  and  Standards  provided  a  requirements-rich  environment  with 
well-defined  processes  for  implementation.  These  processes  and  implementation 
methods  required  the  same  expertise  needed  today  but  applied  in  a  different  context. 
Today’s  environment  is  requirements-poor,  and  the  talented  expertise  must  adjust  to  this 
performance-based  versus  MIL-Spec-based  environment.  The  context  in  today’s 
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environment  is  relationship-based,  not  rule-base,  and  the  survivability  of  this  entire  group 
of  talented  experts  will  depend  on  their  adaptability  to  today’s  context.  Acquisition 
Reform  removed  the  barriers  put  in  place  by  the  MIL-Spec,  rule-based  environment,  but 
it  failed  to  provide  an  adequate  substitute,  which  would  provide  a  robust  process  that  can 
meet  the  supportability  requirements  and  needs  of  the  end  user. 

Proposed:  The  internal  DoD/government  resources  have  a  very  crucial  role  to 
play  regarding  the  supportability  of  all  our  systems  from  design  to  fielded  systems. 
Supportability  is  an  inherently  governmental  function  for  several  reasons:  1)  the 
motivation  of  our  internal  resources  is  in  support  of  the  end  user  needs;  this  perpetuates 
and  enhances  our  positions  and  esteem,  2)  due  to  the  overarching  scope  and  the  long  term 
broad  based  characteristics  of  supportability  issues,  no  one  prime  contractor  could, 
without  conflict  of  interest,  accomplish  these  functions,  and  3)  No  entity  has  or  even 
wishes  to  obtain  the  corporate  knowledge  maintained  by  our  internal  resource  pool.  The 
collaborative  environment  as  is  evident  in  Figures  5  &  6  embeds  the  talented  expertise 
into  the  SSB  process  in  a  way,  which  leverages  these  resources  and  creates  a  value  stream 
for  the  program.  The  relationship  building  characteristics  of  our  internal  resources  is 
very  evident  in  Figure  6  where  this  crucial  resource  takes  “center  stage”  in  enabling  the 
collaborative  system.  Taking  both  figures  (5  &  6)  in  concert  it  is  easy  to  see  how  the 
resource  can  gain  program  equity  and  support  by  reducing  Total  Ownership  Cost  (TOC), 
extend  supportability  of  systems,  and  reducing  program  risk. 

5.  Summary:  Interface  Management 

At  the  core  of  this  collaborative  approach  is  the  management  of  interfaces.  The 
planned  development  of  the  standalone  SSB  system  from  the  overarching  system, 
comprised  of  existing  key  entities,  constitutes  a  collaborative  architecture.  Because  the 
function  and  form  of  these  existing  entities  is  already  defined  and  all  operate  as 
independent  systems,  interfaces  between  these  entities  become  critical  for  effective 
collaboration.  Thus,  interface  management  is  an  important  discipline  that  must  be 
implemented  in  order  for  the  SSB  system  to  be  successful.  A  means  of  effective 
interfacing  is  also  crucial  to  the  success  of  this  system.  A  primary  mode  of 
communication  between  the  entities  will  be  the  World  Wide  Web  and  Navy  &  Marine 
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Corp.  Intranet  (NMCI).  Current  Navy  assets,  such  as  GIDEP,  Cost,  Health  &  Risk 
Models,  DMSMS  notifications,  technical  data  packages,  supportability  procurements  & 
decisions,  etc.,  will  be  shared  via  electronic  means.  The  designated  Assessment  Activity, 
as  part  of  the  Business  Planning  &  Facilitating  function,  will  perform  interface 
management  and  facilitate  communication/data-sharing  methods  in  support  of  the 
Program  Office. 

E.  TIMING 

Technology  advances  pose  greater  problems  to  Navy  procurements  than  for 
consumer  products.  Components,  sub-systems,  and  systems  developed  for  the  military 
have  far  longer  life  cycles  than  their  commercial  and  customer  equivalents.  The  Navy  is 
a  low  volume  consumer  compared  to  the  other  markets.  We  need  to  leverage  commercial 
and  consumer  development  due  to  their  economies  of  scale  to  reach  our  performance 
goals.  This  process  leaves  a  significant  gap  in  the  product  timeline  when  the 
commercial/consumer  life  cycles  are  over  and  suppliers  move  on  to  next-generation 
technology. 


As  indicated  in  Figure  6, 
approximately  five  years  goes  into 
planning,  scheduling  alterations, 
building,  testing,  refreshing 
technology  and  perfonning  software 
updates  for  military  equipment.  In 
contrast,  the  consumer  market  is 
characterized  by  low  development  costs  and  very  rapid  development  cycles,  usually  18 
months.  These  costs  are  recovered  by  the  manufacturer  over  the  short  product  lifetime 
with  high  volume  production  and  sales.  Costs  are  often  less  than  pennies  per  unit  based 
on  the  size  of  the  manufacturing  run.  In  contrast,  the  Navy  procurement  cycle  is 
characterized  by  high  development  costs  over  a  far  lower  volume  production.  The  Navy 
cannot  afford  to  expend  redesign  costs  every  five  or  ten  years  -  not  to  mention  every  six 
to  eighteen  months.  Military  development  costs  are  usually  many  thousands  of  dollars 


Appendix  A  Figure  6:  Technology  Refresh  Cycles 
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per  unit  and  may  in  a  number  of  cases  be  more  than  the  cost  of  the  hardware  itself.  It  is 
not  just  a  matter  of  replacing  one  piece  of  COTS  equipment  or  making  slight  changes; 
software  and  interfaces  to  other  equipment  can  be  affected  or  the  entire  systems  may 
require  redesign  all  the  way  down  the  affected  line. 

The  SSB  does  not  shorten  the  production  cycle  time  for  military  applications.  It 
establishes  a  process  to  maintain  government  inventories  until  a  lifecycle  change  or 
product  improvement  is  desired.  In  this  sense,  SSB  permits  program  management  and 
ultimately  the  end  user  the  flexibility  to  determine  the  time  and  path  to  take  to 
incorporate  system  improvements.  It  provides  manufacturing  /  production  capabilities 
that  meet  the  needs  of  a  fielded  systems  life  cycle.  This  not  only  includes  initial  fielding 
and  spares  but  long-term  replacement  parts,  repairs,  logistical  support  and  testing 
capabilities  over  the  entire  life  cycle  of  the  product.  Additionally,  it  provides  leveraging 
of  small  run  productions  and  rapid  ramp-ups  attributed  to  smaller  businesses. 

A  SSB  team  will  necessitate  collaborative  participation  from  the  program  manger, 
the  SSB  assessment  and  reporting  activity,  the  design  activity,  in-service 
engineering/procuring  agency,  the  prime  contractor  Original  Equipment  Manufacturer 
(OEM),  the  supply  contractor,  and  the  Fleet.  For  a  best-case  scenario,  a  SSB  process 
could  be  executed  in  less  than  one  quarter  of  a  Fiscal  Year  (FY).  However,  the  worse 
case  cycle  could  take  more  than  2%  FYs.  The  significant  delays  in  this  extended  cycle 
hinge  on  legal,  technology  transfer,  supplier  start-up,  and  branding  issues.  These  two 
paths  are  shown  in  the  Figure  8  below.  While  the  first  attempt  at  establishing  a  SSB 
cannot  realistically  be  completed  in  only  one  quarter,  it  similarly  should  not  typically  take 
2%  FYs.  These  timelines  imply  consideration  should  be  given  to  the  establishment  of  a 
SSB  based  on  program  milestones.  Until  systems  enter  at  least  a  limited  production 
phase,  the  efforts  associated  with  creating  a  SSB  may  not  be  warranted.  For  systems  that 
are  in  full  production  and  expecting  at  least  a  five-year  run  the  SSB  process  should  be 
strongly  considered.  A  minimum  three-month  to  IVi  FYs  should  be  the  anticipated 
processing  time  to  create  a  SSB  relationship,  depending  on  regulations  and  complexity. 
Each  individual  program  and  each  OEM  and  SSB  supplier  team  is  likely  to  have  an 
independent  timeline  that  cannot  be  identified  until  the  process  is  in  place. 
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Event  Block  Descriptions: 

1)  Program  Request 

2)  Check/Filter  SSB  Database 

3)  Health  Analysis  of  #3  Red,  Yellow,  Green 

4)  Prepare  an  Obsolescence  Risk  Report  #1,  #2  &  #3 

5)  Program  Office  Review  &  Approval  of  Obsolete 
Component  Parts  Purchase  Request 

6)  NAVY  Procurement  Support  Prepares  Purchase 
Order  Component  Parts 

7)  Identify  SSB  Potential  from  List  -  OEM  candidates 

8)  Contact  OEM  &  SSB  Supplier 

9)  Business  &  Legal  Documentation  in  place 


10)  Transfer  Technology  to  SSB  &  OEM 
Perform  pre-production  readiness  review 
-  May  team  with  NAVY 

11)  SSB  Production  Is*  Piece 

12)  OEM  Quality  Verification  Testing 

13)  Update  SSB  Database 

14)  SSB  Full  Scale  Production 

15)  Order  for  SSB  Assembly  NAVY  Procurement  System 
(NAVTCP)  using  Alternate  Cage  Code  for  SSB  Supplier 

16)  Report  NAVY  Assets  on  hand:  Component  Parts, 
COTS  Assy. 

17)  Customer  -  User  -  Integrator  -  Etc. 


#1  *  Part  Number  assembly  level  Already  SSB 
#2  *  Not  part  #  but  SSB  relationship 

#3  *  No  SSB  Relationship  -  Filter  parts  Microelectronics  only 


Appendix  A  Figure  7:  SSB  Process  Timeline 


Once  in  place,  the  SSB  process  would  typically  be  expected  to  follow  this 
sequence  of  events: 

1)  COTS  manufacturer  identifying  a  drop-in  replacement  part  is  available, 

2)  ECP  and  other  documentation/database  reviews  are  prepared,  coordinated, 
scheduled, 

3)  Legal  verification,  sharing  of  technical  data,  and  configuration  review, 

4)  Developing,  executing  test  and  QA  of  new  COTS  hardware, 

5)  Updating  drawing  package  and  completing  ECP/documentation,  and 

6)  Performing  technical  manual  updates  and  providing  operator  training. 

F.  USER 


The  focus  of  this  paper  is  for  Navy  implementation  of  the  SSB  architecture.  That 
does  not  preclude  other  services,  government  agencies,  or  the  commercial  world  from 
implementing  this  process,  and  in  some  commercial  sectors,  they  already  have. [7) 
Plotkin]  While  we  believe  the  SSB  can  improve  both  processes  and  products  across  DoD 
entities,  there  can  be  many  users  of  the  SSB  process.  The  architecture  of  the  system  is 
defined  such  that  it  could  be  used  by  any  DoD  entity  or  associated  allied  /  Foreign 
Military  Sales  system.  It  has  the  ability  to  be  customized  to  meet  the  needs  of  nearly  any 
end  user  or  decision-maker.  The  key  to  the  SSB  is  to  always  remember  that  it  is  a 
collaborative  effort. 
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Collaborative  systems  are  assembled  and  operate  through  the  voluntary  choices  of 
the  users,  not  through  the  mandates  of  an  individual.  Problems  arise  when  the  developers 
believe  they  have  greater  control  over  the  evolution  of  a  collaborative  system  than  they 
actually  do.  They  may  fail  to  ensure  that  critical  properties  or  elements  will  be 
incorporated  by  failing  to  provide  a  mechanism  matched  to  the  problem. [6)  Maier- 
Rechtin]  The  SSB  architecture  takes  into  its  design  a  robust  collaboration  where  direct 
control  is  impossible  or  inadvisable.  This  Systems-of-Systems  approach  possesses  the 
following  emergent  properties  defining  the  characteristic  of  a  collaborative  system: 

•  SSB  fulfills  valid  purposes  in  its  own  right,  and  will  continue  to  operate  to 
fulfill  those  purposes  if  disassembled  from  the  overall  system. 

•  SSB  is  managed  for  its  own  purposes  rather  than  the  purposes  of  the  whole. 

The  SSB  collaborative  systems  architecture  teams  the  program  manger,  the  SSB 
assessment  and  reporting  activity,  the  design  activity,  in-service  engineering/procurement 
agent,  the  prime  contractor,  OEM,  the  sunset  supply  contractor  and  their  related  parts 
support,  and  the  Fleet.  The  tactical  intent  of  the  SSB  is  to  ensure  that  parts  replacement 
is  transparent  to  the  operators/Fleet  and  that  the  parts  are  available  in  the  supply  chain  in 
a  timely  fashion.  Form  /  Fit  /  Function  /  Features,  the  four  F’s  of  the  supply  chain,  must 
be  one-to-one  with  the  original  product. 

As  a  management  tool,  program  offices  can  use  the  SSB  in  the  acquisition  of  new 
systems  and  in  conjunction  with  in-service  engineering  activities  that  must  continue  to 
procure,  repair,  and  replace  parts  for  the  Fleet.  The  SSB  can  support  integrated  logistical 
support  functions,  which  must  account  for  the  long-term  support  of  fielded  equipment, 
and  must  support  equipment  between  changes  to  the  equipment  base  line.  SSB  will  help 
program  offices  project  the  availability  of  products  that  extend  beyond  the  2-year  POM 
cycle  and  the  3-5  year  implementation  cycle  by  making  use  of  health  /  cost/  risk  models 
which  quantify  the  availability,  supportability  and  obsolescence  of  fielded  systems.  It 
provides  the  program  office  a  tool  to  optimize  its  upgrades,  re-designs,  technology 
refresh  intervals,  and  other  product  enhancement  cycles.  Additionally,  program  risk  is 
reduced  through  the  use  of  the  SSB. 


155 


The  assessment  /  reporting  activity  will  use  the  SSB  to  obtain  and  maintain  a 
stabilized  baseline  and  retain  system  certification.  Use  of  the  SSB  can  be  implemented  at 
various  phases  of  development  such  as:  during  the  initial  integration  and  continued 
support,  the  interoperability  support  of  fielded  systems  subsequent  to  changes  (i.e. 
installation  of  replacement  parts,  firmware,  software  or  hardware  revisions,  etc.).  Also 
the  design  and  development  activities  can  use  the  SSB  to  define  commercial  product 
availability  before  a  design  goes  into  production. 

The  OEM  supplier  will  use  the  SSB  system  to  claim  long-term  life  cycle  support 
of  fielded  products  at  lower  costs  and  less  impact  during  implementation  on  current  and 
future  systems.  Through  the  sunset  supplier  the  OEM  associates  their  name  with  a  long¬ 
standing  relationship  with  the  users.  Concurrently  the  OEM  could  use  the  SSB  system  to 
obtain  compensation/royalties  for  each  item  sold. 

The  SSB  supplier  uses  the  process  to  obtain  new  customers,  new  product  lines, 
and  builds  long  term  relationships  with  the  using  community.  Through  collaborative 
efforts  with  the  assessment  /  reporting  activity  the  SSB  supplier  can  be  assured  of  a 
source  of  supply  for  component  piece  parts  needed  in  producing  the  systems  they  were 
contracted  for,  while  reducing  the  supportability  issues  associated  with  commercial 
products. 

The  user  who  derives  the  most  benefit  from  the  SSB  is  the  Fleet.  It  is  this  end 
user  who  must  operate  our  weapon  systems  and  provide  the  expected  defense  as  defined 
in  our  national  strategic  policies.  The  SSB  system  provides  long  term  stability  to  all 
support  tools,  methods,  and  processes  such  as:  technical  manuals,  testing  procedures  and 
methods,  drawings,  trouble  shooting  information,  parts  lists,  parts  availability,  parts 
replacement  and  other  needed  support.  The  process  improves  system  /  hardware  / 
software  consistency  across  the  Fleet  by  striving  to  provide  better  weapon  system 
configuration  control  leading  to  improved  system  compatibility  between  platforms  or 
ships.  The  SSB  system  will  improve  interoperability  while  reducing  interoperability 
defects. 
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The  outbound  marketing  approach  for  sales  and  distribution  is  to  provide  the  end- 
user  (i.e.,  the  Fleet)  with  a  continuous  supply  of  the  required  product,  at  a  lower  cost, 
while  providing  enhancements  when  and  where  appropriate.  Following  the  original 
procurement  a  secondary  source  provides  the  product  and  distributes  it  via  normal  supply 
chain  (i.e.,  same  P/N,  form,  fit,  function  and  features).  In  so  doing  the  Navy  gains  long 
tenn  supportability,  maintainability  and  operational  readiness. 
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III.  CONCLUSION 


This  paper  has  demonstrated  that  the  SSB  architecture  is  an  affordable  approach 
for  mitigating  program  supportability  risk.  As  a  collaborative  system,  the  information 
that  is  derived  from  the  identification  and  mitigation  of  risk  is  quantifiable  and  will  be 
readily  accessible  to  all  SSB  team  participants.  The  process  takes  into  account  the  fact 
that  the  supportability  of  fielded  hardware  is  defined  by  the  warfighter.  It  extends  the  life 
cycle  and  supportability  of  COTS  and  ensures  a  late-life  cycle  supply  source.  In  so 
doing,  the  SSB  permits  the  DoD  to  be  successful  in  leveraging  commercial  developments 
with  appropriate  economies  of  scale  in  order  to  reach  its  military  perfonnance  goals 
while  offsetting  the  problem  of  diminishing  material. 

The  SSB  system  will  assist  the  Program  Management  Office  (PMO)  by  providing 
infrastructure  support  to  existing  platforms  /  combat  systems.  If  chosen,  this  support  can 
be  provided  early  in  the  development  process,  providing  objective  evidence  in 
demonstrating  COTS  components  ability  to  support  existing  weapon  systems;  thus 
providing  significant  reductions  in  program  risk  related  to  COTS  and  life  cycle 
management.  The  SSB  provides  predictive  information  for  PMO  decision-making 
process.  The  outputs  of  these  trade-offs  and  assessments  will  gain  the  PMO  a  high  level 
of  confidence  with  the  warfighter/customer.  The  process  is  applicable  to  various  DoD 
entities  and  their  contract  strategies.  If  aggressively  integrated  across  DoD,  component 
commonality  could  lead  to  flexible  integrated  logistical  support,  thus  incentivizing  the 
commercial  industry  to  develop  long-tenn  relationships  with  the  sponsors  and  users. 

The  SSB  is  sensitive  to  proprietary  design  rights  and  provides  a  proactive  forum 
for  contractual  negotiations.  The  methods  employed  improve  the  detection  of  product 
supportability  problems  and  provide  sufficient  time  for  analysis  of  alternatives  and 
solutions  in  the  decision-making  processes.  This  technology  assessment  can  be 
implemented  at  the  piece  part,  lowest  replaceable  unit,  subsystem  or  multiple  platform 
level.  The  SSB  approach  is  to  procure  assemblies  when  the  customer  requires  them.  In 
this  way,  it  achieves  significant  and  quantifiable  cost  savings  over  the  product  life  cycle. 
The  process  provides  cost  structures  that  track  and  continually  assess  progress  over  the 
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entire  product  life  cycle.  This  information  pennits  informed  decision-making 
contributing  to  life  cycle  cost  savings  without  the  need  for  Life  of  Type  Buys  (LTB)  at 
the  assembly  level. 

Use  of  the  SSB  will  improve  schedule  flexibility  by  providing  support  options 
that  can  be  tailored  for  the  activities  needed  and  the  warfighter.  It  will  reduce 
provisioning  timeframes  and  place  the  responsibility  for  stockage,  storage,  and  issue  of 
COTS  spares  and  repair  parts  on  the  supply  contractor.  The  SSB  system  enables  many 
activities  and  functions:  immediate  supportability,  elimination  of  government  inventory 
stock  levels,  utilizes  large  commercial  distribution  systems,  no  source  inspection, 
commercial  packaging,  fast  and  direct  delivery  to  the  warfighter,  and  warranty  of 
components.  The  SSB  process  has  definable  and  repeatable  characteristics  that  provide  a 
comprehensive  and  flexible  solution  to  supporting  fielded  hardware.  It  provides 
programs  with  an  independent  utility  for  implementing  COTS  products  and  has  minimal 
or  no  impact  on  system  operational  performance.  Once  implemented,  the  SSB  is  an 
affordable,  expandable,  repeatable  and  reliable  process  that  will  meet  the  users 
performance  expectations.  It  provides  the  best  of  both  worlds.  It  leverages  the  inherently 
governmental  functions  of  the  Navy  supply  process  and  coordinates  with  commercial 
supportability  assets  through  a  thoroughly  meshed  and  maintainable  communication 
network  solution. 
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V.  ADDENDUM 


A.  DATA  DICTIONARY  (FOR  TABLE  1) 

1.  Designing  &  Developing  Products: 

Function:  It  is  during  the  product  development  process  that  the  need  for 

“dependable  &  cost  effective  supportability  insurance  for  fielded  hardware”  must  be 

planned  for  and  implemented  providing  for  a  proactive  approach  to  obsolescence  and 

material  shortages  issues  involving  Commercial-Off-The-Shelf  (COTS)  equipment. 

Primary  sub-functions  consist  of  Parts  Identification  and  SSB/Alternate  Parts 

Identification  whereby  parts  and  assemblies,  which  are  at  risk  for  obsolescence/shortages, 

are  identified  early  and  alternate  parts  or  SSB  parts  are  found  for  a  solution. 

Form:  This  function  may  be  performed  by  Contractor,  Subcontractor,  or  Government 
Activity. 

2.  Acquiring:  Acquisition  Program  Support: 

Function:  It  consists  of  a  number  of  key  program  management  sub-functions 
including  Contracting,  Planning  &  Budgeting,  ILS  Planning,  Vendor 
Selection/Surveying,  Trade-Off  Studies,  and  Health,  Cost,  and  Risk  Analyses  Reporting. 
This  function  provides  the  final  decision  making  authority  for  all  decisions  relating  to 
planning  and  risk  mitigation  efforts  for  equipment  obsolescence,  obsolescence 
management,  and  material  shortages.  The  Contracting  sub-function  will  emphasize  the 
use  of  contract  incentives  for  effective  obsolescence  management  and  participation  in  the 
SSB  process.  The  vendor  source  selection  sub-function  will  also  focus  on  good 
obsolescence  management  practices  and  participation  in  SSB.  The  Health,  Cost,  and 
Risk  Analyses  Reporting  activity  is  part  of  this  Acquiring  function. 

Form:  This  function  is  performed  by  the  Navy  PMO  with  the  support  of  Navy 
Field  Activities,  government  support  Contractors  and  Laboratories  as  directed.  Health, 
Cost,  and  Risk  Analyses  will  be  conducted  by  designated  Navy  Field  Activities  in 
support  of  the  PMO  to  determine  the  extent  of  current  or  potential  obsolescence  or 
material  shortages  issues  and  to  establish  mitigation  priorities.  Results  will  be  delivered 
to  the  PMO  for  subsequent  reporting.  The  Assessment  Activity  will  perform  the  Risk 
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Analysis  and  the  Program  Support  Activity  will  perform  the  Health  &  Cost  Analyses. 
Field  Activities  will  collaborate  to  develop  the  results  of  the  Analyses  to  ensure  a 
complete  assessment. 

3.  Manufacturing/Producing  Product: 

Function:  Primary  sub-functions  associated  with  Obsolescence  Management 

and  Material  Shortages  include  Purchase  Ordering,  Parts  Stockage/Storage,  and 
Manufacturing/Production.  The  Manufacturing/Producing  process  requires  a  supply  of 
components  and  assemblies.  The  Manufacturer  routinely  orders  parts  and  stocks  them 
prior  to  issuance  of  a  work  order  or  bill  of  materials.  Parts  are  kitted  and  processed 
through  assembly  and  test  operations  producing  a  final  product  in  the  end.  The  SSB 
process  identifies  and  procures  obsolete  parts  that  may  be  used  by  the  Manufacturer  in 
cases  where  parts  are  no  longer  available  due  to  Diminishing  Manufacturing  Sources 
Material  Shortages  (DMSMS)  issues. 

Form:  The  function  is  performed  by  the  Prime  Contractor,  associated 
subcontractors,  the  Original  Equipment  Manufacturer  of  a  components  &  assemblies,  and 
Sunset  Suppliers. 

4.  Business  Planning  &  Facilitating: 

Function:  This  function  utilizes  current  Navy  assets  operating  in  a  collaborative 
environment  (system)  with  a  single  focus  on  supportability.  These  assets  must  be 
included  to  develop  relationships  for  the  SSB  system.  This  function  consists  of  the 
following  tasks,  many  which  are  considered  inherently  governmental: 

•  Technology  Roadmapping 

•  System  Health  Modeling 

•  System  Cost  Modeling 

•  Fleet  Failure  Database 

•  Material  Support 

•  Procurement 

•  Stores  (shore/Fleet) 

•  ILS  Planning 

•  Fleet  Support 
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•  Integration  Sites 

•  Supply  Base  Management 

•  Sunset  Supply  Base  Development/Management 

Form:  The  responsibility  for  this  function  is  shared  by  various  Navy  assets  and 
activities  (see  Table  1).  The  first  critical  sub-function  is  Facilitation.  This  refers  to  the 
teaming  and  partnering  function  required  to  enter  into  business  and  teaming  relationships 
with  both  Navy  and  Contractor  organizations  to  establish  a  framework  and  process  for  a 
proactive  management  of  COTS  including  DMSMS  issues.  These  relationships  are 
codified  through  the  generation  of  Memorandums  of  Agreement/Understanding 
(MOA/U)  among  the  Navy,  OEM,  and  Sunset  Suppliers.  The  end  game  of  this  process  is 
to  provide  on-going  Supportability  for  fielded  hardware.  The  Assessment  Activity,  i.e., 
the  Navy  Field  Activity  designated  this  role  by  the  PMO,  will  provide  Quality 
Assessment  to  ensure  the  objectives  of  the  process  are  met.  All  team  members  will 
periodically  perfonn  Technology  Roadmapping  and  assessment  to  ensure  the  most 
affordable  and  reliable  solution.  As  part  of  the  partnering  arrangements  among  prime 
contractor,  OEMs,  and  Sunset  Suppliers,  Purchase  Requests  will  be  generated  which 
ensure  a  reliable  supply  of  sunset  parts  and  assemblies.  Finally,  these  Business  Planning 
and  Facilitation  functions  will  institutionalize  methods  for  proactive  obsolescence  and 
material  shortages  management  across  DoN  and  DoD  (i.e.,  Coordinate  across  DoD). 

5.  Interfacing:  Methods  &  Management: 

Function:  One  of  the  most  important  functions  is  the  manner  in  which 
information  is  shared  among  the  Navy  and  Contractor  organizations.  This  also  includes 
effective  communications  methods.  The  information  technology  revolution  has  provided 
a  number  of  effective  tools,  which  facilitate  the  process  of  mitigating  obsolescence  and 
material  shortages  issues  and  providing  viable  solutions.  Figure  1  illustrates  how  the 
World  Wide  Web  (Internet)  and  the  Naval  &  Marine  Corp  Intranet  (NMCI)  provide 
convenient  On-Line  Accessing  and  are  used  to  network  Navy  and  commercial  activities 
to  provide  quick  and  reliable  solutions. 

Form:  Technical  Data  Exchange  is  perfonned  among  participating  entities  for 

early  indication  of  obsolescence  and  shortage  issues  through  DMSMS  Alerts.  The 
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Government  Industry  Data  Exchange  Program  (GIDEP)  maintained  by  NSWC  Corona 
Division  contains  a  large  repository  of  DMSMS  Notices.  GIDEP  has  approximately 
1600  participants  throughout  Government  and  industry  who  share  DMSMS  information 
and  solutions.  Finally,  ad  hoc  or  Specific  Requests  for  DMSMS  information  can  occur 
via  email,  fax  or  phone  from  and  to  all  participating  entities  in  this  process. 

6.  Performing  Risk  Analysis: 

Function:  One  of  the  first  tasks  will  be  the  performance  of  a  risk  analysis  to 
determine  whether  or  not  there  is  significant  supportability  risk  for  program/hardware 
under  review.  This  should  be  done  in  conjunction  with  the  Health  and  Cost  Analysis 
performed  by  the  Program  Support  Activity  (Health  Modeling  Activity).  The  Risk 
Analysis  function  involves  the  Identification  and  Classification  of  Risk.  Classification 
refers  to  assigning  a  risk  level  to  the  identified  risk  based  on  some  set  of  qualitative  or 
quantitative  criteria.  Risk  levels  are  generally  Low,  Moderate,  and  High.  For  all 
Moderate  and  High  risks,  risk  mitigation  strategies  must  be  planned  and  implemented.  In 
addition  to  health  and  cost  issues,  program  issues,  product/DMSMS  issues,  and  business 
issues  can  also  be  identified  as  risks.  The  final  two  steps  consist  of  Reporting  Risk  and 
Mitigating  Risk.  Risk  will  be  reported  to  the  PMO  to  support  the  Risk  Reporting  sub¬ 
function  in  the  Acquiring  function.  The  end  goal  is  to  put  in  place  strategies  and 
solutions  that  will  mitigate  the  DMSMS  risk  to  a  program. 

Form:  This  is  a  key  function  performed  by  the  Field  Activity  designated  as  the 
Assessment  Activity. 

7.  Performance  Assessment: 

Function:  This  function  consists  of  two  critical  sub-functions.  After  gathering 
much  supporting  data,  a  Purchase  Recommendation  is  made  which  will  hopefully 
mitigate  the  obsolescence  or  material  shortage  risk.  This  function  will  evaluate  the 
effectiveness  of  the  recommendation  prior  to  final  decision-making  by  the  decision¬ 
making  authority  (i.e.,  the  PMO).  In  addition,  Measures  of  Effectiveness  (MOE)  or 
metrics  will  be  established  and  tracked  to  ensure  the  SSB  collaborative  system  is 
providing  best  value  to  the  Fleet.  MOEs  will  be  used  to  manage  the  process  effectively 
and  to  continuously  improve  the  process. 
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Form:  The  Assessment  Activity  will  have  the  responsibility  for  performance 
assessment.  This  will  include  providing  inputs  to  the  purchasing  recommendation  or 
evaluating  the  purchasing  recommendation  made  by  another  entity.  The  Assessment 
Activity  will  take  the  lead  on  metrics  generation  and  tracking.  They  will  have  the 
responsibility  for  reporting  metrics  to  the  SSB  process  community  on  a  periodic  basis. 

8.  Product  Usage: 

Function:  This  is  the  act  of  using  an  alternate  source  of  supply  or  Sunset 
part/component  resulting  from  the  SSB  process. 

Form:  Using  entities  can  include  the  Fleet,  Shore  Activities,  Integration  Sites, 
and  Contractors. 
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ABSTRACT 


The  Systems  Engineering  Development  and  Implementation  (SEDI)  plan  is  one  of 
four  foundational  documents  prepared  in  support  of  the  thesis:  “The  Sunset  Supply  Base: 
Long  Tenn  COTS  Supportability,  Implementing  Affordable  Methods  and  Processes.” 
The  SEDI  plan  defines  a  roadmap  for  implementation  of  the  supportability  concept  and 
when  combined  with  the  other  three  foundational  documents:  The  Sunset  Supply  Base 
Systems  Architecture,  The  Sunset  Supply  Base  Business  Case  Analysis,  and  The  Sunset 
Supply  Base  Marketing  Plan,  establishes  a  transportable,  transferable,  and  repeatable 
supportability  system  for  Commercial  off  the  Shelf  (COTS)  products.  The  SEDI  plan  is 
structured  in  three  sections:  Infrastructure,  Implementation,  and  Measuring  &  Assessing. 
The  approach  is  intentionally  focused  on  supporting  the  person(s)  actually  performing  the 
implementation  function.  Insight  into  the  process  is  provided  by  specific  examples  called 
“Implementation  Experience”  and  embellished  by  “Lessons  Learned”  to  help  enable  the 
implementing  process.  The  tools,  methods,  and  processes  described  are  illustrated 
through  actual  examples  where  these  practices  were  used  to  implement  the  SSB  system 
on  three  Navy  programs.  These  tools,  methods,  and  processes  are  provided  in  detail  in 
the  enclosures  so  that  they  may  be  used,  not  only  for  guidance  but  also  for  a  reusable 
template  for  future  work.  Read  on  and  Enjoy! 


The  nature  of  the  SSB  thesis  topic  and  the  approach  taken  by  the  authors  necessitated  the 
use  of  examples,  templates,  tools,  methods,  and  practices.  These  implementation  tools 
and  deliverable  products  are  illustrated  through  a  set  of  enclosures  referenced  in  the 
thesis  and  its  appendices.  Most  of  the  enclosures  are  static  examples  generated  during 
the  implementation  of  the  SSB  system  on  three  Navy  programs.  However,  other 
enclosures  are  not  static  and  are  therefore  provided  on  a  web  site  (URL: 
http://www.anavision.org/ssb.htm  )  in  the  Excel  format  to  provide  a  dynamic  model  for 
use  by  an  implementer  of  the  SSB  system. 
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17  Steps 

LIST  OF  ABBREVIATIONS  AND  ACRONYMS 

SSB  Implementation  Process 

2  OX 

AN/ASQ-20X  Mine  Hunter 

APM 

Assistant  Program  Manager 

BOM 

Bill  of  Material 

COTS 

Commercial  off  the  shelf 

COTS/NDI 

Commercial  off  the  shelf/Non-developmental  items 

DA 

Design  Agent 

E&MD 

Engineering  and  Manufacturing  Development  phase 

EOP 

End  of  production  date 

EOS 

End  of  service  date 

FAR 

Funding  Allocation  Review 

FAR 

Federal  Acquisition  Regulations 

IEEE  1722 

Capability  Assessment  Tool 

ILS 

Integrated  Logistics  Support 

IPT 

Integrated  Product  Team 

ISEA 

In-service  Engineering  Agency 

LCC 

Life  cycle  cost 

MOA/U 

Memorandum  of  Agreement/Understanding 

MRDB 

Material  Readiness  Database 

MTBF 

Mean  time  between  failure 

NAVICP 

Naval  Inventory  Control  Point 

NDA 

Non-disclosure  agreement 

NSWC  Crane 

Naval  Surface  Warfare  Center,  Crane  Division 

NSWC  Corona 

Naval  Surface  Warfare  Center,  Corona  Division 

OEM 

Original  Equipment  Manufacturer 

ORD 

Operational  Requirements  Document 

PM 

Program  Manager 

PMO 

Program  Management  Office 

POC 

Point  of  contact 

POM 

Program  Objectives  Memorandum 

ROI 

Return  on  investment 

SA 

Systems  Architecture 

SEDI 

Systems  Engineering  Development  and  Implementation  Plan 

SOW 

Statement  of  Work 

SSA 

Software  Support  Agent 

SSB 

Sunset  Supply  Base 

SSDS 

Ship  Self  Defense  System 

TDA 

Technical  Design  Agent 
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I.  THE  SYSTEMS  ENGINEERING  DEVELOPMENT  AND 
IMPLEMENTATION  (SEDI)  PLAN 


A.  PURPOSE 

The  purpose  of  this  plan  is  to  put  into  perspective  the  processes,  methods  and 
tools  needed  to  implement  the  Sunset  Supply  Base  (SSB)  system.  This  document  is 
presented  as  a  “stand-alone”  prescriptive  set  of  actions,  which  can  be  taken  in  the 
establishment  of  an  SSB  system.  However,  this  document  does  not  portend  that  it  is  the 
only  process  or  method  to  establish  such  a  system  but  instead  is  the  method  the  authors 
have  chosen  to  implement  the  SSB  system.  The  document  is  constructed  in  three  major 
sections,  which  follow  a  brief  introduction  to  the  SSB  system  concept.  The  primary 
issues  grappled  with  in  the  SEDI  plan  are  those  faced  during  implementation  and 
encountered  primarily  when  bringing  the  idea  into  reality.  The  first  section  of  the  plan 
addresses  introduction  to  the  program  and  the  infrastructure  needed  to  support  the  effort, 
such  areas  as:  teaming  structure,  computer  resources,  communication  methods,  interface 
with  the  programs,  data  structure  requirements,  management  participation,  etc.  The 
second  section  of  the  plan  covers  the  implementation  of  the  SSB  system  and,  in  turn, 
presents  many  challenges  to  overcome  in  realizing  the  SSB  system.  Examples  of  some  of 
these  challenges  include:  identification  of  the  Commercial  off  the  Shelf  (COTS)  Original 
Equipment  Manufacturers  (OEM),  interface  methods  with  the  OEMs,  interface  with  the 
Program  Management  Office  (PMO),  understanding  the  Program’s  needs  and 
requirements,  building  relationships  between  the  OEMs  and  the  Navy,  identifying 
suitable  partnerships  between  the  OEMs  and  small  build-to-print  suppliers  where 
applicable.  The  final  section  of  the  plan  identifies  methods  and  metrics  to  measure  the 
impact  of  implementing  a  SSB  system,  thereby  providing  adequate  indicators  for  the 
programs  to  assess  the  effectiveness  and  value  proposition  in  using  the  system. 

B.  INTRODUCTION 

The  SSB  concept  is  a  unique  After-Market  approach  to  extend  the  supportability 
of  COTS  products  predicated  on  the  needs  of  Navy  Programs.  The  extension  of  product 
availability,  beyond  the  OEM  assigned  date  to  drop  the  products  as  obsolete  items, 
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provides  stability  to  the  system  baseline  configuration,  during  periods  of  time  between 
installation  and  scheduled  Technical  Refresh/  Insertion.  The  uniqueness  of  the  SSB 
concept  is  evident  through  how  it  is  structured.  The  OEMs  are:  a)  market  driven,  b)  high 
volume  and  high  technology,  c)  their  business  plan  is  driven  by  their  commercial 
customer  base,  with  only  about  0.4  %  of  their  business  going  to  Department  of  Defense 
(DoD)  [1)  Glum,  2)  Robinson,  3)  Hartshorn]  and  d)  experience  fast  update  cycles  (<  18 
months)[l)  Glum,  2)  Robinson,  4)  McDermott].  In  contrast  to  these  OEM  attributes,  DoD 
has:  1)  unique  applications  with  lengthy  life  cycles  (20-40  years),  2)  requires  a  minimum 
technology  refresh  or  update  cycle  of  not  less  than  5  years  [4)  McDermott],  and  3)  have 
operational  readiness  and  maintainability  support  issue  that  span  the  entire  Life  Cycle. 
To  bridge  the  gap  between  the  OEM  business  planning  and  the  Navy’s  need  for  long  term 
support  a  third  party  is  brought  in  if  applicable.  This  is  the  Sunset  Supplier.  The  Sunset 
Supplier  makes  a  contractual  relationship  with  the  OEM  to  produce  the  obsolete  products 
for  the  OEM  customer  base.  The  OEM  transfers  the  intellectual  property  and  assembly 
know-how  to  the  Sunset  Supplier  and  for  this  the  OEM  receives  royalty  on  the  sale  of  all 
products  produced.  Internal  to  the  Navy  are  support  infrastructures  to  ensure 
supportability  of  Sunset  products  by  mitigating  any  component  part  obsolescence  issues 
if  they  exist  on  those  products.  The  infrastructure  and  support  of  the  SSB  process  yields, 
not  only  significant  cost  savings,  but  also  provides  other  benefits,  such  as: 

1)  Supportability  of  products  defined  by  customer  need  (5,  10,  15,  20  years.) 

2)  Life  Cycle  Cost  (LCC)  savings,  due  to  no  life-time  buy  at  the  assembly  level  is 
needed,  so  the  assemblies  are  procured  as  the  customer  requires  them. 

3)  Reparability  of  assemblies  over  the  designated  life  cycle(5,  10,  15,  20  years) 

4)  Hardware/Software/Firmware  stability  between  Technology  Refresh/Insertion 
Cycles. 

5)  Significant  reduction  in  program  risk  as  related  to  COTS  and  life  cycle 
Management. 

6)  Improved  schedule  flexibility  and  support  options  that  can  be  tailored  for  Fleet 
needs. 

7)  Minimal  or  no  impact  on  system  operational  performance.  The  performance 
will  remain  constant  through  the  use  of  exactly  the  same  part:  form,  fit,  and 
function  replacement,  which  has  been  made  by  the  alternate  manufacturer,  the 
Sunset  Supplier. 
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II.  INITIATION  AND  MANAGEMENT  OF  A  SSB  SYSTEM 


A.  GETTING  STARTED 

The  key  in  beginning  a  successful  implementation  effort  is  in  choosing  an 
appropriate  application  where  the  benefits  of  the  SSB  system  can  be  realized.  Although 
not  limited  to  addressing  the  issues  gennane  to  COTS  product  supportability  issues,  this 
area  was  identified  as  an  unresolved  and  potentially  “ripe”  candidate  to  yield  a  large 
Return  On  Investment  (ROI)  from  implementing  the  SSB  system.  The  funding  for  such 
an  effort  must  come  from  some  entity,  such  as  institutional  sponsors,  PMO,  local  field 
activities,  or  through  some  kind  of  initiative.  Since  the  effort  is  designed  to  solve 
supportability  issues  of  fielded  hardware  it  seems  only  natural  to  identify  a  Program 
which  is  having  problems  in  supporting  their  fielded  COTS  products.  From  our 
experience  with  Programs,  making  the  switch  from  products  built  using  military 
specifications  to  COTS  products,  the  differential  in  the  life  cycle  management  between 
the  two  approaches  is  profound,  so  much  so  that  to  our  knowledge  every  COTS 
implementation  brings  with  it  a  whole  set  of  unresolved  risks.  Resolution  or  management 
of  these  risks  is  the  primary  purpose  of  implementing  the  SSB  system.  Therefore  one  of 
the  prime  targets  in  obtaining  support  and  funding  resides  in  the  PMO  since  it  is  the 
Program  Manager  (PM)  who  is  ultimately  responsible  for  the  life  cycle  support  of  the 
products  delivered  to  the  Fleet. 

The  SSB  system  being  a  collaborative  effort  will  require  extensive  teaming  and 
partnering  both  within  your  local  organization  and  external  to  your  local  functions.  The 
subject  of  teaming  and  partnering  is  so  important  to  the  success  in  initiating  and 
management  of  the  SSB  system  that  each  step  of  the  process  described  below  will 
illustrate  certain  external  interfaces  that  demand  participation  in  these  activities.  These 
external  activities  must  be  supported  through  an  internal  local  teaming  effort  since  the 
implementation  effort  is  broad  in  scope  and  cross  functional  in  nature.  Establishment  of 
a  local  support  team  is  described  in  the  last  portion  of  this  section  and  is  intentionally 
placed  after  the  SSB  system  requirements  so  that  the  uninitiated,  new  implementer  can 
scope  the  task.  Although  the  local  teaming  effort  description  is  provided  after  the 
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description  of  other  implementation  actions,  the  actual  sequence  of  events  should  take 
place  with  the  local  teaming  effort  being  perfonned  first.  The  local  support  team  is  the 
enabler,  which  allows  successful  accomplishment  of  all  other  activities.  The  external 
interfacing  requirements  are  provided  first  to  establish  the  boundaries,  goals,  scope, 
objectives,  and  purpose  as  background  for  formation  of  an  internal  local  team.  The 
reader  is  advised  to  study  the  SSB  system  requirements  prior  to  establishment  of  a 
support  team. 

B.  DEFINE  THE  CHALLENGES 

The  SSB  system  is  built  on  a  collaborative  System  Architecture  (SA),  which 
means  that  an  entity  must  choose  to  join  the  system  and  stay  with  the  system.  The 
agreement  to  implement  such  a  system  must  have  compelling  logic  and  be  substantiated 
through  some  track  record  or  justifying  data.  Even  with  pilot  program  examples  and  an 
implementation  track  record,  a  program  without  experience  with  the  SSB  system  will 
want  to  know:  “How  will  this  apply  to  my  Program?”,  “What  will  be  the  impact  in  our 
unique  situation?”,  “What  assurances  can  you  give  me  that  the  SSB  system  will  be 
appropriate  for  my  program?”,  etc.  The  questions  go  on  and  on  but  are  focused  on  one 
primary  issue:  Is  this  the  right  thing  for  our  program?  To  answer  any  of  these  questions, 
you  as  the  implementer  will  need  to  do  your  homework.  If  this  is  not  already  a  program 
you  are  working  on,  you  will  need  to  make  it  your  program  by  finding  out  as  much 
information  as  possible  about  it.  The  immediate  goal  should  be  gathering  information 
regarding  the  Program;  below  is  a  starter  list  of  important  areas  or  documents  which  may 
be  of  help: 

1)  What  is  the  program  scope  and  hardware  application? 

2)  Is  the  system  certified:  certified  combat  weapon  system,  safety  certified,  etc.? 

3)  Review  of  reference  documentation:  Operational  Requirements  Document 
(ORD),  Mission  Profile,  Operational  Requirements,  etc.? 

4)  What  organizationally  driven  policies  and  requirements  regarding  COTS  are 
impacting  the  Program? 

5)  Contractual  arrangements:  Perfonnance  Based  Logistics,  Organic  Maintenance, 
Full  Service  Contract,  etc. 

6)  Financial  issues:  Budget,  funding,  Programs  Objective  Memorandum  (POM), 
etc. 
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7)  COTS  issues  and/or  support  efforts  attempted  or  on-going 

8)  What  type  of  Configuration  Management  process  is  implemented  in  support  of 
the  Program? 

9)  System  Software  impacts  due  to  COTS 

10)  Integrated  Logistic  Support  (ILS)  approach 

11)  What  stage  in  the  life  cycle  is  the  Program  hardware  that  needs  to  be  supported: 
legacy,  Engineering  &  Manufacturing  Development  (E&MD),  new  design, 
etc.? 

12)  What  is  the  fielding  schedule  and  how  many  platforms,  for  how  long? 

13)  Are  there  any  intentions  or  planned  tech  refresh/insertion  points  (i.e.  years 
between  tech  refreshes)? 

14)  Program  organizational  structure 

15)  Current  COTS  efforts 

16)  Points  Of  Contact  for  primary  responsibility  in  the  area  of  COTS  management, 
ILS,  refresh  issues,  etc. 

C.  APPROACHING  THE  PROGRAM  OFFICE  OR  DESIGNATED 
REPRESENTATIVES 

Each  program  opportunity  will  be  different  and  a  customized  approach  must  be 
developed  to  support  the  unique  program  needs.  Even  though  the  program  requirements 
will  be  unique,  the  basic  needs  can  be  met  through  modification  of  documentation  used 
on  other  previously  successful  programs  because  the  basic  needs  of  most  programs  are 
similar.  In  this  portion  of  the  SEDI,  the  subject  matter  is  decomposed  by  functional 
activities  that  need  to  be  addressed  to  implement  an  SSB  effort.  The  functional  activities 
are  supplemented  with  examples,  illustrated  through  documentation  from  successful 
implementation  efforts  on  three  pilot  programs.  The  list  of  these  functional  activities 
includes:  initial  contact,  defining  Points  of  Contact  (POC),  establishing  roles  and 
responsibilities,  and  initial  estimates  regarding  the  effort.  Important  to  note  is  that  the 
SSB  system  is  a  departure  from  the  traditional  government  oversight  approach  and 
requires  dedicated  involvement  in  all  aspects  of  the  implementation  effort.  Buy-in  of  the 
effort  at  the  highest  levels  in  the  program  is  of  utmost  importance.  As  a  new  and 
different  method  in  solving  the  COTS  supportability  challenges,  there  will  be  push-back 
from  many  individuals  in  the  program  organization,  who  will  find  it  easier  to  say  no,  than 
to  take  the  risk  of  an  innovative  concept. 
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Implementation  Experience: 

In  the  case  of  SSDS  MK-1,  the  lead  engineer  responsible  for  the  long  term 
supportability  of  the  system,  during  the  kick-off  meeting,  noticed  push-back  and 
questioning  by  the  Integrated  Logistics  Support  (ILS)  community  of  the  proposed  SSB 
effort.  He  then  stepped  in,  to  emphasize  that  the  program  has  chosen  the  SSB  system 
direction.  After  receiving  the  blessing  of  the  Captain  of  the  program  with  regard  to  the 
approach,  the  lead  engineer  stressed,  that  regardless  of  the  perceived  risks  the  SSB 
system  has  been  chosen  because  the  decision  was  based  on  the  long  term  value 
proposition  to  the  program,  so  overcome  the  resistance  to  the  idea  and  support  the  effort. 
The  AN/AQS-20X  Assistant  Program  Manager  (APM)  had  tasked  the  SSB  effort  directly 
and  assembled  a  team  to  work  on  the  ILS  support  for  the  program.  The  team  in  general 
expressed  apprehension  and  skepticism  about  the  probability  of  success  of  the  SSB 
system.  The  APM  was  frank  and  explicit  in  his  demands  that  the  program  direction  is  to 
implement  the  SSB  system  on  COTS  products. 

Lessons  Learned  from  this  Experience: 

Your  best  bet  as  an  implementer  of  the  SSB  system  is  to  receive  the  highest  level 
of  buy-in  within  the  program  and  to  have  that  supporter  understand  the  value  added 
proposition  in  using  the  system.  At  the  various  organizational  levels  in  the  program,  it  is 
easier  to  say  no  and  retrace  the  steps  that  were  used  in  previous  times,  then  it  is  to  try 
new  methods  with  their  associated  risks.  The  importance  of  Top-Down  roll  out  of  the 
SSB  effort,  although  not  absolutely  necessary,  is  one  of  your  best  avenues  to  success. 

Like  all  first  impressions,  the  initial  contact  with  the  Program  Office  or  their 
chosen  representatives  in  introducing  the  SSB  system  will  have  a  great  impact  on  your 
ability  to  enlist  their  support  and  obtain  their  sponsorship.  Although  there  exists  a 
multitude  of  independent  attributes  that  contribute  to  making  a  good  first  impression,  our 
inclination  is  to  focus  on  three  predominate  factors.  First  and  most  important  from  the 
program’s  perspective  will  be  the  professionalism  and  knowledge  of  the  person  providing 
the  presentation.  As  will  be  evident  during  the  implementation  of  the  SSB  system,  an  in- 
depth  knowledge  of  many  of  the  characteristics  of  Systems  Engineering  must  be 
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exercised  to  have  an  effective  implementation  effort.  An  understanding  of  the  following 
areas  is  considered  necessary  in  order  to  handle  emerging  issues: 

1)  Good,  people  skills  including  teaming  skills 

2)  Knowledge  of  contracting  methodologies,  constraints,  and  impacts 

3)  The  ability  to  build  relationships  and  partnerships 

4)  Understanding  the  design,  development,  deployment,  testing,  and  support 
processes  employed  by  the  program 

5)  The  ability  to  learn  the  specific  manufacturing  processes  used  to  make  the 
COTS  products 

6)  Be  able  to  develop  and  implement  a  project  plan  specifically  for  the 
implementation  of  the  SSB  system 

7)  Well  practiced  negotiations  skills 

The  next  factor  that  will  help  or  hinder  your  initial  efforts  relies  on  what  you  are 
presenting  to  your  focused  audience.  Available  in  Enclosure  (1)  is  a  presentation  used  in 
briefing  PMO,  Original  Equipment  Manufacturers  (OEM),  and  potential  SSB  suppliers. 
The  presentation  provides  a  general  conceptual  view  on  how  the  SSB  functions, 
introduces  the  primary  players,  and  the  expected  outcomes.  This  presentation  has  been 
used  as  an  initial  “calling  card”  to  introduce  the  idea  and  has  been  met  with  success  in 
illustrating  the  potential  value  proposition  provided  through  use  of  the  system.  As  the 
implementer,  your  focus  must  be  to  understand  each  and  every  slide  presented  because 
the  ideas  are  identified  through  pictures,  notional  representations,  diagrams,  etc.  without 
a  lot  of  wordy  explanations  that  would  clutter  up  the  presentation.  The  building  of  a 
common  foundation  about  the  SSB  system  is  the  objective  of  the  presentation  and  details 
with  long  explanations  can  be  provided  later.  Additional  information  in  support  of  the 
presentation  are  typically  used  to  add  certain  details  which  improves  the  understanding  of 
the  SSB  systems  goals.  Enclosure  (2)  is  an  executive  summary  which  provides  a  concise 
high  level  description  of  the  system.  Enclosure  (3)  is  an  article  from  the  “COTS 
Journal”,  [5)  Plotkin].  This  article  identifies  the  use  of  a  system  almost  exactly  like  the 
SSB  system,  as  an  industrial  best  practice  where  it  is  implemented  to  support  certain 
industries  that  are  capitally  intensive  and  configuration  constrained  (i.e.  paper  mills, 
power  generation  facilities,  petroleum  distillate  plants,  etc.) 
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The  second  focus  area  that  must  be  addressed  very  early  on  is  the  uniqueness  of 
the  effort  and  that  the  SSB  effort  is  not  a  duplication  of  other  activities  currently  being 
funded.  The  SSB  Systems  Architecture  (SA)  is  specifically  designed  to  leverage  the 
traditional  sustainment  engineering  functions/activities  by  adding  additional 
functionality;  that  when,  taken  in  concert  with  the  traditional  methods  yields  new 
capabilities  not  provided  by  either  approach  used  independently.  The  SSB  system  was 
designed  specifically  to  address  open  issues,  which  bring  undefined  large  risks  to  the 
program.  Through  implementing  the  SSB  system,  new  previously  undisclosed 
information  regarding  details  about  the  components  which  make  up  the  COTS  products  is 
obtained  through  a  collaborative  effort:  between  you  as  the  representative  of  the  program 
and  the  COTS  OEM  or  SSB  supplier.  Since  by  the  very  nature  of  the  procurement 
process  for  COTS  products,  only  the  product  is  purchased  with  minimal  supporting 
information.  In  contrast  to  the  nominal  methods  of  interfacing  with  the  suppliers  of 
COTS,  usually  through  purchase  orders,  the  SSB  system  invokes  the  exchange  of  product 
details  typically  by  entering  into  a  Non  Disclosure  Agreement  (NDA).  Enacting  an  NDA 
allows  you,  as  the  program  representative,  visibility  regarding  the  component  make  up  of 
the  COTS  assembly  and  it  is  this  knowledge,  which  allows  you  to  identify,  quantify,  and 
manage  the  obsolescence  risk.  It  is  the  combination  of  the  collaboration,  the  commitment 
through  the  NDA,  knowledgeable  assessment  of  risk,  and  teamwork  that  defines  the 
uniqueness  of  the  SSB  efforts.  To  our  knowledge  no  other  system  has  been  successfully 
implemented  to  meet  these  objectives.  Enclosure  (4)  is  an  example  of  a  Statement  of 
Work  (SOW)  depicting  statements  in  support  of  the  unique  attributes  of  the  SSB  system. 
To  help  the  new  implementer  who  may  need  an  example  in  crafting  an  agreement  with 
the  OEM  or  SSB  supplier,  a  “fill  in  the  blank”  NDA  is  provided  in  Enclosure  (5). 

Implementation  Experience: 

In  both  MK-1  &  MK-2  Ships  Self  Defense  Systems  (SSDS)  programs,  the  idea  of 
having  this  kind  of  visibility  was  very  difficult  for  the  ILS  community  to  accept  because  it 
was  not  part  of  the  normal  interfacing  routine.  The  engineering  community  on  the  other 
hand  had  typically  signed  NDAs  previously,  usucdly  for  design  evaluations,  and 
understood  the  significance  and  utility  of  having  access  to  the  detailed  information.  The 
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ILS  community  was  confused  with  the  difference  in  roles  between  NSWC  Crane  -  the 
sustainment  support  activity  which  identified  the  obsolescence  code  (red,  yellow,  green), 
on  the  piece  part  components  level  -  and  NSWC  Corona  -  the  activity  signing  the  NDAs 
and  obtaining  the  component  parts  lists  for  each  COTS  assembly.  It  took  hours  of 
explaining  before  the  ILS  community  was  able  to  identify  the  uniqueness  of  each  function 
and  assure  themselves  there  were  no  duplication  of  efforts. 

On  the  20X  program  the  ILS  community  had  much  the  same  issues  with  much  the 
same  resolutions.  Although  in  the  case  of  the  20X  program  an  additional  issue  of 
justifying  cost  effectiveness  of  the  SSB  efforts  exacerbated  the  situation.  The  cost 
effectiveness  of  using  the  SSB  system  will  be  dealt  with  later  in  this  implementation  plan 
but  the  issue  is  brought  forth  here  to  illustrate  how  various  issues  can  be  compounded 
and  if  not  handled  appropriately  may  derail  the  process. 

Lessons  Learned: 

The  teams  you  will  be  working  with  will  have  members  that  have  various  levels  of 
understanding  and  responsibility  resulting  in  different  perspectives  of  your  endeavors. 
The  key  to  success  is  to  take  the  time,  be  patient,  and  where  possible  develop  a  tight 
relationship  with  other  team  members  doing  the  obsolescence  assessments.  The  ILS 
community  may  be  harder  to  reach  at  first  although  they  will  eventually  be  very 
supportive  of  the  SSB  efforts.  The  engineering  community  seems  to  catch  on  to  the  idea 
quickly  but  also  brings  to  the  table  a  lot  of  skepticism. 

As  a  result  of  the  information  gathering  process  you  accomplished  in  learning 
about  the  program,  several  Points  of  Contact  (POC)  probably  have  emerged.  Some  of 
these  POCs  are  within  the  PMO  while  others  are  part  of  the  organizational  structure  that 
support  the  program.  Typically  there  are  one  or  more  PMO  individuals  who  provide 
guidance  to  the  group  members  that  implement  the  required  functions.  The  members  that 
perform  the  functional  support  for  the  program  are  as  important  to  enabling  the  SSB 
system  as  the  PMO  is  in  sponsorship  of  it.  Close  working  relationships  need  to  be 
cultivated  with  other  activities  to  yield  the  most  optimum  outcome. 


183 


Field  activities  tasked  by  the  PMO  to  provide  the  needed  aspects  of  support  must 
be  interfaced  with  smoothly  or  at  least  non-confrontationally.  For  example,  the  activity 
that  supports  the  software  design  and  maintenance  will  be  impacted  by  the  SSB  system 
due  to  the  stabilization  of  the  equipment  baseline  provided  as  part  of  the  system.  On  the 
other  hand,  not  all  answers  will  be  found  through  the  hardware  and  in  some  instances  a 
small  software  change  can  mitigate  the  impact  of  the  changes  in  the  COTS  hardware 
products.  Due  to  the  interactive  nature  of  COTS  hardware/software  it  will  be  most 
productive  to  work  as  a  team  and  to  include  the  activity  supporting  the  program’s  system 
software. 

Many  programs  will  have  their  Integrated  Logistic  Support  (ILS)  functions 
accomplished  through  one  of  the  field  activities  and  therefore  another  important  activity 
to  work  with  in  enabling  the  SSB  system.  The  engineering  support  efforts  (i.e.  In-Service 
Engineering  Agent  (ISEA),  Technical  Design  Agent  (TDA),  Software  Support  Agent 
(SSA),  Design  Agent  (DA),  etc.  )  must  be  considered  an  integral  part  of  the  long  term 
supportability  solution  thereby  directly  impacting  the  SSB  efforts.  Depending  on  the 
situation,  many  and  in  some  cases,  most  of  the  important  POCs  you  as  the  SSB  system 
implementer  will  need  to  work  with  will  reside  at  the  prime  contractor.  These  contractor 
POCs  may  include  design  engineering,  logistics,  purchasing,  configuration  management, 
reliability  engineering,  manufacturing,  and  others,  but  their  involvement  will  depend  on 
what  was  written  into  the  contract.  Again,  the  homework  you  did  early  on  will  come  in 
handy,  in  understanding  the  contract  requirements. 

Implementation  Experience: 

One  of  the  primary  documents  used  to  implement  the  SSB  system  is  a  complete  list 
of  the  COTS  items  used  in  the  program’s  system.  In  the  SSDS  MK-1  system  we  interfaced 
with  the  ISEA  and  the  prime  contractor  to  develop  a  complete  list  of  COTS  products. 
Although  this  task  does  not  seem  difficult  it  was  more  complicated  than  initially 
envisioned  because  certain  items  were  purchased  as  COTS  products  then  modified  by  the 
prime  resulting  in  a  prime  generated  part  number  on  the  Bill  of  Materials  (BOM). 
Tracing  down  all  the  COTS  products  required  the  teamwork  of  the  prime  contractor,  the 
ISEA,  and  the  ILS  functions.  We  experienced  the  same  situation  when  deeding  with  the 
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MK-2  system,  however  in  this  case  the  prime  contractor  was  the  primary  source  with 
minor  inputs  from  other  functional  areas.  As  an  important  side  note,  the  list  of  COTS 
products  and  OEMs  is  a  living  document,  which  will  change  as  more  information  is 
gathered  and  the  knowledge  of  the  Program’s  system  increases. 

Lessons  Learned: 

Implementing  the  SSB  system  requires  the  implementer  to  take  a  Systems 
Engineering  approach  in  dealing  with  all  aspects  of  the  Program,  and  the  POCs  you  will 
interface  with  may  come  from  almost  any  area,  such  as  contracts,  logistics,  engineering, 
financial  business  management,  procurement,  ISEA  &  TDA  support,  legal,  etc.. 
Regardless  of  which  functional  area  the  POC  you  interface  with  comes  from,  the  key  to 
success  will  be  effective  communication  to  achieve  understanding  about  the  goals  and 
objectives  of  the  Program  encompassing  the  long  term  supportability  issues  at  hand. 
Since  each  community  (i.e.  contracts,  legal,  financial )  has  a  language  or  unique 
meanings  to  concepts  and  words,  it  is  important  to  learn  how  to  appropriately  address 
each  subject  to  achieve  a  common  understanding  of  your  implementation  efforts.  This  is 
not  an  easy  task  so  do  not  take  it  for  granted,  that  “what  you  meant  to  say  is  what  they 
heard”,  ask  for  feedback  and  address  concerns. 

The  knowledge  obtained  thus  far  in  initiating  a  SSB  system  implementation  effort 
will  be  helpful  in  formally  documenting  the  roles  and  responsibilities  of  all  groups  and 
functions  working  as  a  team  in  support  of  the  program.  Each  program’s  organizational 
structure  and  their  approach  and  teaming  membership  may  be  quite  different,  therefore 
these  aspect  necessitate  a  unique  and  customized  documentation  package.  From  our 
implementation  experience,  most  efforts  require  the  development  of  a  team  charter  and  a 
management  plan  which  is  approved  through  the  Program  Management  Office  (PMO). 
The  charter  identities  at  a  very  high  level  the  goals  and  objectives  for  the  group  as 
perceived  by  the  approving  PMO  authority.  These  high  level  guidelines  provide  the 
overarching  objectives  and  constraints  the  working  group  must  achieve.  Enclosure  (6) 
provides  an  example  of  the  PMS  461  -  SSDS  COTS  Working  Group  Charter.  Since  most 
of  the  requirements  and  objectives  identified  in  this  charter  are  at  such  a  high  level,  they 
can  apply  to  most  any  similar  working  group  and  can  therefore  provide  a  starting  point 
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for  your  next  implementation  effort.  Enclosure  (7)  is  the  SSDS  COTS  Working  Group 
Management  Plan,  it  identifies  how  the  high  level  requirements  were  translated  into 
specific  structures,  processes,  and  reporting  requirements.  These  documents  will  take 
time  and  effort  to  prepare  and  once  complete  are  available  as  a  reference  to  the  team, 
however  the  real  value  of  this  documented  approach  is  when  changes  in  team  structure  or 
membership  take  place.  Having  the  documented  guidelines,  roles  and  responsibilities, 
processes,  and  requirements  in  this  way  identifies  a  constant  baseline  upon  which  a  team 
can  function  during  periods  of  disruption  or  change.  In  some  circumstances  it  may  be 
necessary  to  start  at  the  very  beginning,  that  is;  each  member  must  provide  their 
perception  of  their  position  on  the  team  and  identify  from  their  perception  other 
member’s  positions  along  with  every  member’s  interface  requirement.  As  each  member 
briefs  the  team,  the  information  and  knowledge  exchanged  will  help  solidify  functional 
and  practical  reasons  for  inclusion  of  each  member.  Sometimes  there  will  be  conflicts  or 
duplication  of  effort  but  you  are  at  the  beginning  of  the  effort  and  this  is  the  best  time  to 
find  out  about  those  kinds  of  issues.  Enclosure  (8)  is  an  example  of  a  “Membership: 
Roles  &  Responsibilities  Presentation”  that  was  used  during  the  formation  of  the  20X 
working  group. 

The  efforts  thus  far  have  dealt  with  getting  to  know  the  Program  environment,  the 
people,  and  the  interfaces,  now  you,  as  the  implementer,  must  answer  the  question,  “How 
much  will  this  cost?”.  There  is  no  way  to  avoid  the  question  so  answer  it  as  honestly  as 
possible.  The  issue  in  answering  this  question  at  the  beginning  is  that  you  probably  do 
not  have  enough  information  to  provide  a  reasonable  estimate  because  it  depends  on  so 
many  independent  variables.  These  independent  variables  may  include  but  are  not 
limited  to:  1)  the  age  of  the  design,  2)  the  life  cycle  phase  of  the  COTS  products,  3)  how 
many  OEMs  are  involved,  4)  how  many  COTS  configurations,  5)  how  much  support  will 
you  receive  from  the  rest  of  the  working  group  teaming  members,  6)  how  long  must  the 
COTS  items  support  the  system,  7)  what  level  of  funding  does  the  PMO  consider 
appropriate,  etc.  So  back  to  the  sticky  question  -  “How  much?”  -  in  the  Implementation 
Experience  section  below  are  some  rules  of  thumb  used  previously  and  these  may  prove 
valuable  in  constraining  the  boundaries  of  the  cost  risk  as  perceived  by  the  PMO.  For 


186 


example,  the  initial  estimate,  provided  to  each  of  the  three  programs  we  implemented  the 
SSB  system,  was  1  Vi  man  years;  1  man  year  for  programmatic  interface  and  Vi  man  year 
for  infrastructure.  Although  this  estimate  should  not  be  used  across  the  board  it  was 
acceptable  to  the  programs  for  an  initial  estimate.  Important  to  note  is  that  our  estimates 
were  based  on  some  in-depth  knowledge  of  the  programs  we  chose  and  the  willingness  of 
our  local  management  to  support  us  if  it  became  necessary.  Another  approach  to 
answering  the  -“How  much?”  -  question  is  to  identify  an  incremental  time  period  to 
research  some  of  the  driving  factors  then  to  develop  realistic  estimates  and  propose  them 
back  to  the  Program.  From  our  implementation  experience,  a  three  month  exploration 
period  will  yield  the  most  important  information  which  will  be  useful  to  the  support  team, 
if  the  PMO  decides  to  fund  you  or  not,  this  makes  the  task  ‘value  added’  to  the  program 
regardless  of  the  decision.  Later  on  in  this  document  will  be  examples  of  data  collected 
that  show  a  Return-On-Investment  (ROI)  proving  the  value  added  proposition  of 
implementing  the  SSB  system,  these  values  should  be  used  to  provide  a  notional  but 
realistic  expected  outcome  of  the  effort. 

Implementation  Experience: 

To  initiate  our  implementation  efforts  we  cheated  as  much  as  we  could  by 
assessing  the  programs  we  were  already  doing  work  for  and  by  doing  this  we  avoided  a 
lot  of  uncertainty  with  regards  to  the  people  and  the  programmatic  details.  With  this 
jump-start  of  information  we  still  had  much  to  find  out  about  the  COTS  products.  To  put 
the  problem  into  perspective  the  task  to  find  the  specific  information  that  would  be  useful 
in  future  work  included  identifying:  which  configuration  of  the  COTS  items  were  being 
used,  who  were  the  manufacturers,  how  many  of  each  configuration  were  in  the  system, 
and  where  the  manufacturers  are  located.  This  was  a  mundane  but  daunting  task.  The 
SSDS  MK1  system  for  example  has  a  Bill  of  Materials  (BOM)  that  is  over  12,600  lines 
long  and  out  of  all  these  items,  we  identified  274  instances  where  COTS  items  were  used. 
Because  of  multiple  uses  of  a  configuration,  the  274  instances  boiled  down  to  only  49 
significant  items.  We  then  evaluated  the  configurations  and  found  that  only  34  OEMs 
were  involved.  This  evaluation  and  grouping  effort  required  inputs  from  almost  every 
team  member  and  it  was  a  critical  element  in  making  the  overall  implementation  feasible 
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and  the  estimating  process  for  future  work  possible.  It  took  a  little  over  a  month  to  nail 
down  a  reasonable  list  that  received  consensus  by  the  entire  team.  If  we  were  to  start 
from  scratch  to  accomplish  the  same  task  we  would  probably  ask  for  three  months  to 
produce  a  reasonable  estimate. 

Lessons  Learned: 

You  will  find  out  that,  unless  your  program  is  extremely  unique  in  this  area,  no 
one  person,  no  single  documentation  package,  or  even  a  cross  functional  IPT  will  know 
all  the  COTS  used  within  a  medium  size  system.  One  of  the  prevalent  problems  is  that  in 
many  instances  COTS  products  are  modified  in  hardware  or  software  by  the  prime 
contractor  to  meet  the  systems  requirements.  Once  modified,  these  products  will  receive 
a  unique  number  assigned  usually  by  the  prime  contractor,  this  action  hides  the  COTS 
product  in  such  a  way  that  it  is  nearly  impossible  to  extract  usable  information  using 
automated  methods.  It  is  important  for  the  program  to  identify  these  instances  so  that  the 
risk  of  using  the  COTS  products  can  be  managed  and  even  though  the  product  has  been 
modified  it  is  based  on  the  COTS  product,  which  carries  with  it  an  inherent  obsolescence 
risk.  When  developing  a  list  of  COTS  items  used  in  your  system,  dig  deep  and  be  ruthless 
in  identifying  every  instance. 

D.  INFRASTRUCTURE:  THE  BACKDROP  FOR  SUCCESSFUL 

IMPLEMENTATION 

Planning  a  successful  implementation  of  the  SSB  system  requires  more  than 
merely  obtaining  your  Program’s  support,  it  will  require  a  supportive  infrastructure  that  is 
well  thought  out  and  structured  in  a  way  to  allow  future  growth  capability.  The  design  of 
an  infrastructure  must  support  and  reflect  the  goals  for  the  SSB  system.  These  goals  are 
identified  in  the  System  Architecture  (SA)  document  and  are  provided  below  for  review: 

1)  To  be  able  to  identify,  quantify,  and  mitigate  supportability  risks  to  the 
program. 

2)  Extend  the  life  cycle  and  supportability  of  COTS 

3)  Provide  infrastructure  to  support  existing  platforms/systems  in  support  of  the 
PMO 

4)  Achieve  significant  and  quantifiable  cost  savings  over  the  product  life  cycle 

5)  A  reliable,  affordable,  repeatable  and  expandable  process  that  meets  the 
customer’s  performance  expectations. 
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6)  Institutionalized  methods  for  proactive  COTS  management  and  DMSMS 
issues. 

7)  Leverage  Navy  and  commercial  supportability  assets  and  provide  a  networked 
solution. 

8)  Leverage  across  Navy  programs  with  extended  applicability  through  contract 
strategies,  methodologies  and  incentives  to  entice  commercial  industry 
participation. 

9)  Forecast  budget  requirements  in  support  of  the  programs,  warfighters,  and 
consumer. 

10)  Improve  schedule  flexibility  and  support  options  of  system  upgrades  or 
development  initiatives. 

The  objectives  of  the  SSB  system  are  to  provide  long  tenn  relationships,  preserve 
and  protect  intellectual  property  rights,  and  provide  the  interface  management  resulting  in 
a  long  term  COTS  supportability  solution.  All  of  these  goals  and  objectives  must  be 
supported  through  the  infrastructure,  that  when  developed  may  be  completely  transparent 
to  the  identified  attributes.  To  develop  such  an  infrastructure  we  have  found  it  useful  to 
partition  these  attributes  into  functional  areas  or  tasks. 

The  support  infrastructure,  we  have  found  useful,  is  composed  of  two  functional 
areas:  programmatic  support  and,  for  lack  of  a  better  word,  infrastructure  support.  The 
programmatic  support  consists  of  three  global  functions  accomplished  through  seven 
primary  tasks  identified  below: 

Programmatic  Functions: 

1)  Interface  with  the  Program  Office  &  Infrastructure  Team 

2)  Details  pertaining  to  specific  program  characteristics  - 

a.  Number  of  systems 

b.  Number  of  COTS  assemblies  used  and  location 

c.  Insight  into  the  prime  contractors  assembly  call  out 

d.  Reliability  numbers  (i.e.  failure  rates,  MTBF,  etc.) 

e.  Fielded  systems  concept  of  deployment  and  operation 

3)  Provide  Recommendations 

a.  Buy  quantities 

b.  Technology  refresh  intervals  and  interim  support  strategies. 
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Programmatic  Tasks: 

1)  Obsolescence  reporting 

2)  Provide  purchase  recommendations 

3)  Interface  with  OEM,  SSB  supplier  and  Program  Office  support  teams 

4)  Involvement  in  applicable  program  activities 

5)  Identify  and  implement  program  specific  flow-down  requirements 

6)  Address  quality  issues  (hardware/software,  documentation,  etc.)  and  interface 
with  the  OEM,  SSB  supplier,  Program  Office,  prime  contractor,  etc. 

7)  Cost  assessment  based  on  Life  Cycle  Costs  (LCC)  and  the  unique  opportunity 
to  impact  these  costs  through  implementation  of  the  SSB  system. 

The  tasks  and  functions  of  the  programmatic  support  point  of  contact  (POC),  have 
been  and  will  continue  to  be,  the  focus  of  this  SEDI  model.  Almost  all  the 
Implementation  Experience  and  Lessons  Learned  documented  in  the  SEDI  model  are  to 
provide  insight  for  the  practitioner  to  ease  the  implementation  burden.  The  examples 
provided  in  the  enclosures  may  be  used  with  minor  modifications  or  in  some  cases 
directly  applied  by  the  programmatic  POC.  Even  though  the  programmatic  POC  is 
critical  throughout  the  SSB  implementation  process,  this  POC  must  rely  on  supportive 
structures  provided  by  an  infrastructure  team.  The  inherent  interdependency  of  the 
relationship  between  these  two  entities  is  crucial  in  providing  the  SSB  systems 
functionality.  Although  both  functions  (programmatic  and  infrastructure)  are  of  a 
technical  nature,  the  programmatic  POC  handles  the  business  and  program  issues  while 
the  infrastructure  team  deals  mainly  with  engineering  and  configuration  management 
issues. 

The  infrastructure  team  provides  many  of  the  capabilities  identified  in  the  goals 
and  objectives  for  the  SSB  system,  such  as  expandability,  transportability,  reusability, 
leveraging  capability,  configuration  management  and  control,  affordability  and  Life 
Cycle  Cost  assessments.  The  characteristics  embedded  within  the  infrastructure  team 
incorporate  traditional  Sustainment  Engineering,  Integrated  Logistic  Support,  and 
Configuration  Management  functions  by  employing  a  Systems  Engineering  approach  as 
illustrated  below.  These  functions  are  embedded  within  the  approach  but  not  duplicated 
by  the  approach,  an  important  distinction  that  must  not  be  overlooked.  To  illustrate  this 
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point  we  will  use  the  Sustainment  Engineering  function  as  an  example.  The  Sustainment 
Engineering  function,  for  all  three  programs  we  implemented  the  SSB  system  on,  was 
performed  by  other  field  activities.  In  particular,  the  obsolescence  analysis,  at  the  piece 
part  or  assembly  level,  was  perfonned  by  NSWC  Crane;  since  this  field  activity  has  the 
in-house  expertise,  appropriate  tools/methods  and  a  successful  track  record  of 
performance.  By  teaming  with  the  Sustainment  Engineering  function  at  NSWC  Crane 
we  did  not  need  to  develop  such  a  capability  but  instead  we  were  able  to  leverage  this 
Navy  asset  for  the  good  of  the  programs.  In  performing  our  function  in  implementing  the 
SSB  system  we  brought  the  piece  part  or  component  list  of  the  COTS  assemblies  to 
NSWC  Crane  for  analysis.  These  lists  provided  insight  into  the  COTS  assemblies 
obsolescence  issues  whereby  identification,  assessment,  and  management  of  the 
obsolescence  risk  to  the  programs  could  be  evaluated.  The  risk  management  capability  is 
a  new  characteristic,  which  emerges  through  the  combined  efforts  of  Sustainment 
Engineering  and  implementation  of  the  SSB  system  and  unachievable  using  either  or  both 
systems  independently.  The  scope  and  breath  of  the  infrastructure  team  will  depend  on 
how  you  intend  to  execute  the  needed  functionality.  It  will  also  depend  on  if  the  needed 
functions  are  perfonned  in-house  or  provided  through  a  teaming  relationship  as  described 
above.  Regardless  of  the  type  of  structure  you  design  into  the  infrastructure  team  the 
following  lists  of  functions  and  tasks  should  be  accomplished  or  covered: 

Infrastructure  Functions: 

1)  Interface  with  the  programmatic  POCs 

2)  Establish  and  maintain  the  OEM/SSB  supplier  relationships 

3)  Develop  a  database  with  appropriate  controls  and  access  rights 

a.  Creation  of  the  database  structure 

b.  Define  methods  for  updating  data  and  controlling  access  rights 

c.  Provide  mechanisms  for  continuous  maintenance 

4)  Provide  a  central  site  to  enable  open  and  private  communication  (i.e.  specific 
server  location,  web  site,  bulletin  board,  etc.) 

5)  Perform  analysis  on  the  data  gathered 

6)  Coordinate  with  all  support  activities  where  applicable  through  programmatic 
POC  (ISEA,  TDA,  SSA,  DA,  etc.) 

7)  Report  findings  or  status 
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8)  Coordinate  with  other  programmatic  POCs  that  could  be  affected  by  the 
reporting  results 

9)  Perfonn  on-site  reviews  at  the  SSB  suppliers  to  assure  schedule,  cost  and 
quality  performance  is  maintained. 

Infrastructure  Tasks: 

1)  Database  Management 

a.  Program  generated,  prioritized,  COTS  lists,  at  the  assembly  level 

b.  OEM  provided,  component  piece  parts  lists  and  drawings  detailing  the 
make-up  of  the  assembly  level:  Cautionary  Note  -  These  parts  lists  and 
drawings  supplied  through  the  OEM  are  obtained  through  entering  a  Non- 
Disclosure  Agreement  (NDA)  and  therefore  necessitates  special  handling 
along  with  restricted  access. 

c.  Development  of  a  relational  database;  Design,  Management,  and 
Maintenance 

d.  Infonnational  query  and  data  extraction 

2)  Obsolescence  Risk  Management 

a.  Receive  COTS  assemblies  list  from  programmatic  POC 

b.  Perform  assembly  level  obsolescence  health/risk  at  that  level 

c.  Retrieve  from  the  COTS  OEMs  the  component  piece  parts  list  for  each 
assembly. 

d.  Filter  the  component  piece  parts  list  and  condense  list  to  active 
components  for  which  predictive  obsolescence  tool  are  readily  available 
and  used  as  industry  standards.  Exceptions  to  this  filtering  process  are 
handled  on  a  case-by-case  basis. 

e.  Perform  a  piece  part  level  obsolescence  health/risk  analysis  at  the 
component  piece  part  level. 

f.  Prepare  an  Obsolescence  Risk  Report  for  the  program  in  an  agreed  upon 
format,  by  working  with  the  programmatic  POC 

g.  Perform  continuous  monitoring  of  the  component  piece  parts  by  reviewing 
impact  of  ongoing  obsolescence  notices  posted  by  the  component  piece 
part  manufacturers. 

3)  Interface  with  OEMs  and  programmatic  POCs 

a.  Initiate  the  relationship  with  the  Original  Equipment  Manufacturers 
(OEM)  and  act  as  the  primary  interface  with  them  throughout  the  life  of 
the  SSB  system. 

b.  Initiate  the  relationship  with  the  SSB  suppliers  and  act  as  the  primary 
interface  with  them  throughout  the  life  of  the  SSB  system  and  perform  on¬ 
site  reviews  of  SSB  suppliers  using  an  IEEE  1722  type  evaluation. 
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c.  Interface  as  required  with  other  program  support  activities  (i.e.  ISEA,  ILS, 
TDA,  etc.) 

d.  Teaming  with  the  programmatic  POC  and  the  other  program  support 
activities,  define  and  document  the  expectations  and  required  support  from 
the  infrastructure  team.  Typically  these  expectations  and  requirements  are 
embedded  in  a  Statement  of  Work  (SOW),  a  tasking  document,  or  in  a 
Memorandum  of  Agreement/Understanding  (MOA/U)  between  the 
implementing  activity  and  the  Program  Office.  Examples  of  these  types  of 
documents  are  available  in  Enclosure  (9)  -  “Tasking  Documentation”. 

e.  As  opportunities  emerge,  the  infrastructure  team  is  responsible  for  the 
interface  with  other  activities  such  as  other  field  activities,  professional 
societies,  government  initiatives,  industry  working  or  focus  groups,  etc. 
that  provide  potential  improvements  or  impacts  to  the  SSB  system  and  its 
implementation. 

E.  TEAMING:  THE  ENGINE  OF  IMPLEMENTATION 

The  functions  and  tasks  described  in  the  preceding  portions  of  this  document 
identify  some  of  the  primary  areas  your  internal  local  team  must  accomplish  and  even 
though  the  list  is  extensive  it  is  not  an  all-inclusive  list.  There  are  many  approaches  to 
teaming  (i.e.  Tiger  teams,  working  groups,  functional  teams,  project  teams,  etc.)  that  may 
provide  the  needed  mechanisms  to  support  the  SSB  system.  However,  because  the 
objective  in  initiating  the  SSB  system  will  require  development  of  tools,  methods,  and 
processes  to  implement  the  system,  an  Integrated  Product  Development  (IPT) 
environment  is  recommended.  During  our  implementation  experience  we  found  the  IPT 
approach  established  a  firm  foundation  that  structured  the  resources  and  leveraged  the 
available  assets.  Most  of  the  individuals  on  our  local  team  had  previous  IPT  experience 
so  we  did  not  need  to  start  out  with  teaching  them  basic  IPT  skills.  For  the  few  members 
with  no  previous  experience  it  was  -  “Trial  by  Fire”  -  through  On-the-Job  training;  an 
experience  less  than  optimum  but  still  doable.  If  this  will  be  your  first  encounter  with 
functioning  in  an  IPT  environment  we  recommend  formal  training  as  a  way  to  expedite 
the  learning  process.  As  identified  in  the  functions  and  tasks  descriptions  provided 
earlier,  every  functional  position  on  the  IPT  relies  on  all  the  other  positions  and  must  be 
worked  simultaneously  and  with  a  high  degree  of  coordination,  to  keep  the  tasks  on  track. 
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Formation  of  the  SSB  IPT  was  done  only  after  buy-in  from  the  local  management 
had  been  received.  To  receive  this  buy-in,  required  several  steps  that  are  briefly  outlined 
here  to  provide  the  implementer  with  a  possible  roadmap. 

1)  Initial  presentation  of  the  SSB  system,  see  Enclosure  (1) 

2)  Provide  additional  reading  material,  see  Enclosures  (2),  (3),  &  (10) 

3)  Develop  a  project  plan  for  SSB  system  Implementation,  see  Enclosure  (11) 

4)  An  informal  request  for  resources  to  stand  up  the  proposed  IPT 

Establishment  of  the  SSB  system  IPT  was  initiated  by  gathering  up  the  requested 
candidates  and  presenting  all  the  materials  provided  to  the  management  to  gain 
endorsement  then  receive  each  member’s  buy-in.  The  next  steps  in  forming  the  IPT  was 
to  develop  the  Mission  &  Vision  statements  (see  Enclosure  (12)),  a  set  of  roles  and 
responsibilities  (i.e.  secretary,  Leader,  etc.)  (see  Enclosure  (13)),  and  define  the  team 
norms  and  ground  rules  (see  Enclosure  (14)).  With  these  baseline  documents  in  place  the 
team  then  defined  our  internal  structure  to  meet  the  functional  and  tasking  requirements. 
This  led  to  the  formation  of  two  sub-teams:  the  Programmatic  Team  and  the 
Infrastructure  Team.  The  sub-teams  formed  along  these  functional  boundaries  helped  in 
providing  communications  paths  in  the  functional  area,  however  each  sub-team  was 
given  the  caveat  that  the  entire  SSB  system  implementation  is  the  primary  focus  of  the 
IPT  and  sub-IPTs  must  support  that  overarching  goal. 

Implementation  Experience: 

Our  IPT  chose  to  have  identified  positions  within  the  team  (leader,  secretary,  etc.) 
and  split  or  decompose  the  functions  into  two  teams.  The  group  was  a  small  team 
composed  of  four  team  members  on  the  infrastructure  team  that  were  loccd  plus  four 
remote  members  from  another  field  activity  (NSWC  Crane),  cdso  there  were  three 
members  on  the  programmatic  team.  Something  to  think  about  is  the  issue  of  conflict 
resolution.  In  our  case  the  usucd  manner  of  handling  conflict  took  place  within  the 
context  of  the  norms  or  ground  rules  for  the  IPT  but  not  cdways.  The  primary  architect  of 
the  SSB  system,  took  the  team  lead  of  the  IPT  and  was  asked  to  mediate  or  provide 
guidance  in  some  situations  thereby  acting  as  the  “fined  word”  or  “last  stop”.  This 
“fined  word”  acted  as  a  process  control  typicedly  used  to  remove  a  “stumbling  block”  or 
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“break  a  log  jam  ”  whereby  the  process  could  keep  moving  forward.  Most  of  these 
instances  required  a  short  term  decision  that  would  have  long  term  impacts  therefore  in 
our  unique  situation  it  seemed  natural  to  depend  on  the  lead  architect.  When  setting  up 
an  SSB  system  it  may  prove  useful  to  designate  an  individual  to  act  in  this  primary 
architect  or  team  lead  position  because  your  implementation  will  also  be  unique  in  its 
own  way. 

Lessons  Learned: 

Working  within  an  IPT  environment  where  tasks  are  highly  coupled  and 
inherently  dependent  on  one  another,  it  is  important  to  keep  a  vigilant,  watchful  eye  out 
for  the  team’s  response  when  errors  occur.  When  mistakes  or  errors  occur  the 
perturbations  are  felt  in  almost  every  team  product  and  team  members  are  real  sensitive 
about  the  impacts  to  their  work.  There  will  be  no  way  to  avoid  the  domino  effect  of  a 
mistake  and  therefore  the  entire  team  must  put  extra  effort  into  placing  a  positive  spin  or 
positive  challenge  to  the  remedy  of  these  errors.  The  IPT  environment  encourages  its 
members  to  share  risks  and  in  taking  risks,  some  mistakes  will  be  made,  expect  them, 
over  come  them  as  a  team,  and  the  result  will  be  a  creative  robust  teaming  environment. 
F.  SUMMARY: 

Lets  take  a  minute  and  summarize  what  your  implementation  efforts,  so  far,  have 
addressed  and  assess  how  these  steps  will  help  your  future  efforts  in  bringing  the  SSB 
system  to  life.  Thus  far  we  have  defined  the  purpose,  objectives,  expectations  and 
approach  in  implementing  the  SSB  system.  We  have  discussed  various  methods  and 
approaches  in  obtaining  buy-in  from  both  the  local  management  and  the  target 
program(s).  The  function  and  task  descriptions  have  been  identified  for  an  infrastructure 
to  support  an  SSB  implementation  along  with  development  of  the  tools  and  methods  to 
enable  the  IPT  environment  including:  Mission  &  Vision,  Roles  &  Responsibilities,  and 
Norms  &  Ground  Rules.  All  the  aforementioned  materials  lay  the  ground  work  for  the 
actual  implementation  efforts  covered  in  Section  2:  The  Practitioners  Manual.  It  is 
important  to  understand  that  the  actual  implementation  efforts,  can  and  often  do,  happen 
concurrently  with  development  of  the  foundational  activities  described  in  Section  1: 
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Initiating  and  Management  of  an  SSB  system,  the  impact  of  the  of  your  foundational 
work  will  be  evident  during  the  actual  implementation  process. 
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III.  SECTION  2:  THE  PRACTITIONERS  MANUAL: 


This  section  of  the  SEDI  was  prepared  to  provide  implementation  details 
regarding  the  SSB  system  and  the  unique  value  added  tasks.  This  description  will 
illustrate,  that  when  combined  with  Sustainment  Engineering,  ILS,  procurement,  and 
other  program  support  function,  the  new  support  system  yields  a  risk  management 
method  for  long  term  supportability  of  COTS  products  contained  in  Navy  systems  in  all 
phases  of  their  life  cycle,  from  design  to  fielded  systems.  The  Practitioners  Manual  is 
partitioned  into  two  major  subject  areas:  Defining  the  COTS  assembly  list  and 
prioritizing  it  with  respect  to  programmatic  impact,  and  the  “17  Steps”  -  SSB 
Implementation  Process  identifying  concurrent  and  sequential  activities.  The  following 
methods,  tools  and  processes  are  embedded  within  these  subject  areas:  Reporting  Status 
of  the  COTS  prioritized  list  and  the  “17  Step  Process”,  Obsolescence  Health/Risk 
Reporting,  Purchase  Recommendation  for  Obsolete  components,  and  database 
management  requirements.  These  implementation  tools,  processes  and  methods,  can  and 
usually  are,  concurrent  activities  with  the  events  described  in  section  1  -  Initiation  and 
Management  of  a  SSB  system.  The  programmatic  POC  is  the  active  participant  using 
“The  Practitioners  Manual”  as  a  roadmap  during  the  implementation  process.  The 
functions  and  tasks  of  the  programmatic  POC  are  outlined  in  section  1  of  the  SEDI  and 
will  require  the  POC  to  focus  on  communication,  teaming,  negotiating,  and  partnering 
skills  to  yield  a  successful  SSB  system  implementation. 

A.  DEFINING  THE  COTS  ASSEMBLIES  LIST 

The  path  to  a  successful  SSB  system  implementation  begins  with  knowing  what 
to  implement  the  system  on  and  what  impact  the  process  will  have  on  the  program(s). 
This  process  will  require  coordination  with  every  major  player  in  the  PMO  and  all  the 
support  activities  and  functions.  The  importance  in  defining  an  accurate  comprehensive 
COTS  assembly  list  cannot  be  overstated  because  it  will  be  the  basis  for  defining  how  all 
other  SSB  system  implementation  activities  and  plans  are  to  be  accomplished.  Since  the 
definition  of  COTS  will  vary  from  application  to  application  the  process  of  identifying 
those  items  that  fit  into  the  COTS  category,  will  be  an  iterative  and  recursive  learning 
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process.  During  this  process,  as  the  COTS  list  matures  and  becomes  more  accurate  and 
complete,  it  provides  a  communication  tool  that  further  refines  the  understanding  of  the 
implementation  task  from  the  perspective  of  the  team  and  from  your  perspective.  This 
process  will  help  identify  the  SSB  system  participation  with  respect  to  the  overall  support 
efforts. 

The  best  starting  point  in  developing  an  adequate  COTS  list  will  depend  on  the 
program,  the  application,  and  the  customer’s  expectations.  Typically  a  program  will  have 
several  different  kinds  of  lists  of  hardware  and  software,  at  various  stages  of  indenture 
and  description.  It  will  be  necessary  to  understand  the  meaning  of  the  list  and  how  it  fits 
within  the  overall  system  being  studied.  Some  of  the  more  common  types  of  lists 
include:  the  Configuration  Management  List,  the  As-built  Configuration  List,  and  the  Bill 
of  Material  (BOM).  For  our  purposes  we  will  refer  to  the  main  source  in  developing  the 
COTS  list  as  the  BOM  even  though  it  is  only  one  of  the  potential  sources  of  data.  In 
some  cases  you  will  receive  several  lists  that  together  should  make  up  most  or  all  items  of 
interest.  It  may  appear  that  this  part  of  the  process  should  be  straight  forward,  but  on  the 
contrary;  collection  of  this  data  may  take  quite  a  lot  of  effort  and  absorb  significant 
amount  of  time.  The  key  in  keeping  the  task  manageable  is  to  immediately  start  the 
iterative  and  recursive  review  and  buy-in  process.  Usually  what  will  happen  is  a  list  will 
be  provided  to  you  and  will  contain  either  too  little  or  too  much  data.  Your  first  effort  is 
to  assess  and  understand  what  infonnation  you  now  have  and  how  it  applies  to  the  system 
under  consideration.  In  the  case  of  being  supplied  with  too  much  data,  you  will  need  to 
filter  out  extraneous  data  whereby  producing  a  condensed  list  of  just  COTS  items.  During 
this  filtering  process,  interface  with  the  primary  team  members  (i.e.  prime  contractor,  the 
design  agent,  the  ISEA,  procurement,  and  ILS)  is  very  helpful.  Regardless  of  how  you 
accomplish  the  task  or  how  careful  you  are,  the  list  you  create  will  be  wrong.  Don’t 
worry  about  it  but  deal  with  it  through  communication.  Use  the  first  cut  at  the  list  as  a 
communication  device  to  all  other  team  members  requesting  feedback  and  any  additional 
information  they  (the  team  members)  could  provide.  It  will  be  enlightening  to  your 
efforts  to  find  out  that  no  two  people  agree  on  what  should  be  on  your  list,  it’s  level  of 
detail  or  indenture,  and  the  differing  view  points  on  the  need  to  generate  such  a  list.  This 
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is  the  time  to  exert  your  leadership  role  in  getting  the  SSB  system  off  to  a  strong  start  so 
distribute  the  filtered  list  to  the  team  and  when  you  receive  feedback  -  immediately 
revise  and  re-issue  the  list.  This  process,  like  many  others  in  the  SSB  system,  is  iterative 
and  recursive,  so  if  you  are  waiting  for  the  final-final  product  before  initiating  the  next 
step  in  the  process  -  don’t  -  because  you’ll  never  get  to  the  next  step;  be  willing  to  deal 
with  some  data  that  is  incomplete.  The  data  you  are  collecting  will  continue  to  change 
throughout  the  process,  however  one  saving  grace  is  that  there  will  be  a  subset  of  data 
(i.e.  the  predominate  COTS  items)  that  do  not  change;  and  this  fact  allows  for  the  next 
step  in  the  process  to  be  initiated.  In  the  case  of  too  little  data  such  as  a  particular  item 
chosen  because  of  the  programmatic  risks  if  limited  to  the  singular  item  it  may  be  a 
potential  start  to  an  implementation  effort.  However,  unless  a  more  encompassing  task 
can  be  developed  there  will  be  no  assurances,  that  the  SSB  system  can  effectively  attain 
its  full  potential.  It  is  important  to  remember  that  the  purpose  of  the  SSB  system  is  to 
provide  COTS  long  term  supportability  for  the  fielded  hardware  and  incomplete 
implementation  will  yield  an  undetennined  risk  to  the  program’s  supportability  plans  for 
those  COTS  not  identified  on  the  COTS  list  and  therefore  not  covered  by  the  SSB 
system.  As  the  SSB  system  implemented  you  probably  will  not  be  able  to  drastically 
influence  the  approach  the  program  support  team  will  start  with  -  too  much  or  too  little 
information  -  but  your  primary  task  at  this  point  is  to  understand  what  you’ve  received 
and  what  implication  that  data  has  on  the  SSB  system  effort. 

Implementation  Experience: 

To  illustrate  the  large  differences,  an  implementer  may  expect,  in  generating  a 
COTS  list,  a  high  level  description  of  how  lists  were  generated  for  the  SSDS  programs 
and  the  AN/AQS-20X  program  are  discussed.  The  SSDS  MK1  COTS  list  generation 
process  started  with  evaluating  the  as-built  configuration  list  (referred  to  as  the  BOM ) 
that  was  provided  as  a  12,600  line  excel  worksheet.  This  was  too  much  data  and 
therefore  required  filtering,  a  time  consuming  process.  About  2  days  of  work  reduced  the 
list  to  about  200  potential  candidates  for  the  first  COTS  list.  During  this  process  we 
realized  that  the  MK1  and  MK2  SSDS  systems  shared  many  of  the  same  COTS  Original 
Equipment  Manufacturers  (OEMs)  and  some  of  the  exact  configurations.  It  seemed 
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logical  that  a  combined  list  could  yield  some  leverage  in  subsequent  process  steps.  In  an 
effort  to  define  the  combined  list  we  distributed  the  MK1  list  to  both  program  teams 
(SSDS  MK1  &  SSDS  MK2)  and  requested  feedback.  The  amount  of  feedback  was  almost 
overwhelming  and  the  effort  took  about  12  revision/re-issue  cycles.  The  result  of  the 
effort  produced  a  combined  list  of  about  115  configurations  from  34  OEMs.  The  SSB 
systems  implementation  effort  now  seemed  doable  and  reasonable  with  the  additional 
advantage  that  these  boundaries  received  both  teams  buy-in  and  consensus.  In  contrast 
to  the  SSDS  program  method  in  generating  the  COTS  list,  the  20X  program  was  much 
different.  During  the  first  team  meeting  for  the  20X  support  team,  the  prime  contractor 
provided  a  list  of  COTS  configurations  and  the  associated  OEMs.  Although  the  list  was 
small,  about  20  configurations  from  5  OEMs,  it  represented  the  majority  of  the  COTS 
electronic  products  in  the  20X  system  and  received  immediate  buy-in  from  the  team.  It  is 
important  to  note  that  this  list  was  the  initial  list  produced  from  drawing  of  the  20X 
system  prior  to  baseline  configuration  for  production,  therefore  this  list  was  considered  a 
“soft  list  ”  expected  to  change  in  support  of  the  production  baseline. 

Lessons  Learned: 

Development  of  the  COTS  list  for  a  program  of  interest  is  an  important  task, 
which  lays  the  foundation  for  the  subsequent  SSB  system ’s  implementation  efforts.  This 
task  is  never  complete  and  will  require  continuous  monitoring  and  updating.  The  key  to 
success  during  this  development  process  is  the  iterative  and  recursive  approach,  which 
uses  the  list  generating  process  (revise  and  re-issue  cycles )  as  a  communication  tool  to 
cultivate  consensus  within  the  team. 

Defining  the  COTS  list  through  consensus  of  the  program  support  team  should  be 
complimented  with  an  effort  by  the  entire  team  to  prioritize  the  list.  This  prioritization 
provides  an  implementation  roadmap  of  appropriate  sequential  steps  to  guide  the 
implementer’s  activities.  Additionally,  the  priority  identification  provides  guidelines  that 
can  be  very  useful  during  budgeting  and  funding  activities.  The  prioritization  activity 
typically  takes  place  once  the  COTS  list  has  reached  some  level  of  maturity  where  the 
changes  in  the  list  produce  minor  impacts.  By  this  point  in  time  the  entire  team  is 
familiar  with  the  contents  of  the  list  and  some  of  the  interrelationship  that  exists  between 
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the  items  on  the  list  and  with  the  system  in  general.  The  activity  in  defining  the  priority 
for  each  item  is  a  teaming  function  where  all  members  must  actively  participate  to  yield 
an  adequate  product.  The  dependence  of  hardware  to  software  is  of  key  concern  in 
assigning  the  priority  levels.  In  some  circumstances,  some  assemblies  will  be  inherently 
linked  to  other  assemblies  such  that  a  change  to  one  impacts  the  other  and  therefore  need 
to  be  grouped  as  like  priority  in  the  overall  scheme  of  the  list.  Enclosure  (15)  provides  the 
combined  SSDS  MK  1&2  prioritized,  COTS  list,  in  a  state  of  maturity  about  half  way 
through  the  process.  During  the  development  of  this  workbook  there  were  several 
spreadsheets  that  were  used  to  develop  the  all-up  list  described  in  worksheet  4.  This 
worksheet  illustrates  the  identified  COTS  OEMs,  the  configurations  of  interest,  the  points 
of  contact  at  the  OEM,  the  amount  of  assemblies  needed  for  the  next  10  years  at  a  50% 
and  99%  confidence  levels  to  show  the  potential  buy  quantities  range,  and 
implementation  notes;  all  arranged  in  prioritized  order.  This  worksheet  was  used 
extensively  to  communicate  the  what,  who,  how,  and  when  regarding  the  SSB  system 
implementation  activities.  Enclosure  (16)  presents  the  same  workbook  at  a  much  later 
time,  a  review  of  spreadsheet  4  shows  how  this  communication  tool  has  been  modified  to 
give  an  update  of  the  implementation  process  and  identify  actions  and  recommendations 
to  the  budgeting  planning  activities.  Using  these  tools  helps  organize  your  efforts  and 
aids  in  communication  with  the  rest  of  the  team. 

B.  THE  “17  STEPS”  -  SSB  SYSTEM  IMPLEMENTATION  PROCESS 

The  “17  Steps”  SSB  system  implementation  process  was  first  described  in  the 
System  Architecture  as  a  method  to  describe  and  document  the  list  of  sequential  steps 
needed  to  implement  the  SSB  system.  The  “17  Steps”  process  is  not  meant  to  be  a  stand 
alone  process;  instead  the  process  is  intended  to  have  the  support  of  the  tools,  methods, 
and  processes,  identified  in  section  1  of  the  SEDI  and  preempted  by  a  well  defined 
prioritized  COTS  list.  The  “17  Steps”  are  used  by  the  programmatic  POC  as  the 
implementation  roadmap  and  each  step  will  require  interactive  participation  with  the 
program  support  team  and  the  internal  infrastructure  team  to  produce  the  desired  result. 
The  prioritized  COTS  list  becomes  pivotal  in  starting  the  steps,  due  to  the  reliance  on  the 
list  for  identification  of  which  OEMs  are  involved  and  the  associated  lower  level  of 
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configurations  encompassed.  The  process  is  designed  to  be  applicable  to  each 
configuration  of  assembly  whereby  the  applicable  steps  are  addressed  independently  for 
each  step  and  each  configuration.  There  are  natural  groupings  such  as  all  configurations 
from  a  particular  OEM,  in  which,  if  the  OEM  chooses  not  to  participate  then  all 
configurations  are  by  default  excluded.  Barring  unusual  constraints  on  the 
implementation  process  implementation  of  the  process  steps  takes  place  at  the  assembly 
configuration  level  and  are  independent  of  all  other  configurations.  Figure  1  -  “17  Steps” 
-  SSB  Implementation  Process,  provides  a  notional  depiction  of  the  process  steps  and  is 
supplemented  with  -  step  definition.  This  figure  and  definitions  are  also  provided  as 
enclosures  for  use  by  new  implementers  to  assure  consistency  and  repeatability  of  the 
process  (see  Enclosures  (17)  &  (18)).  The  purpose,  objective  and  resulting  output  of  each 
step  impacts  the  implementation  effort  and  will  be  discussed  in  detail. 


Appendix  B  Figure  1:  “17  Steps”  -  SSB  Implementation  Process 


1.  Case  Open 

The  “17  Step”  process  flow  begins  with  an  initial  statement  -  Case  Open  -  to 
designate  that  there  is  a  need  to  do  some  preliminary  work  before  starting  the  process. 
The  “Case  Open”  descriptor  is  dependent  on  first  being  able  to  define  the  COTS  list  and 
preferably  having  it  prioritized  before  implementation.  As  identified  in  proceeding 
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paragraphs,  the  COTS  list  does  not  need  to  be  finalized,  only  mature  enough  to  be  stable 
as  a  prerequisite  in  beginning  the  “17  Steps”.  Other  concurrent  activities  will  most  likely 
take  place  during  the  process  step  initiation,  these  other  activities  may  include: 
infrastructure  development,  team  formation  activities,  and  program  support  team 
interfacing. 

2.  Step  1.0  -  Check/Filter  SSB  Database 

Steps  1.0  through  Step  5.0  are  handling  the  COTS  items  at  the  assembly  level  and 
the  configurations  are  grouped  by  OEM.  In  this  first  step  the  new  list  of  COTS 
assemblies  are  checked  against  the  current  COTS  database  to  see  if  any  leverage  can  be 
obtained  due  to  previously  accomplished  work.  The  objective  for  this  step  is  to  identify 
the  scope  of  work  that  still  needs  to  be  accomplished.  The  final  result  of  this  process  step 
is  to  define  the  candidate  list  of  COTS  assemblies  for  further  investigation.  The  resultant 
output  from  this  step  will  fall  into  one  of  three  categories:  1)  the  specific  configuration 
and  by  default  the  OEM  are  already  in  the  database  whereby  most  of  the  work  has  been 
done  the  only  remaining  issue  is  to  extend  the  current  application  to  the  new  program  of 
interest,  2)  the  specific  configuration  of  interest  has  not  been  a  sunset  candidate  however, 
the  OEM  has  participated  in  the  SSB  system  and  a  SSB  relationship  has  been  set  up, 
leaving  the  next  action  in  this  instance  would  be  to  explore  the  possibility  of  the  OEM  to 
consider  additional  configurations,  and  3)  the  OEM  has  not  participated  in  the  SSB 
system  and  by  default  no  configurations  have  been  considered. 

3.  Step  2.0  -  Supportability  Analysis  Acquired  (EOP,  EOS  dates,  MTBF, 
etc.) 

The  purpose  of  this  step  is  to  identify  at  the  assembly  level  supportability  criteria 
that  will  help  quantify  the  obsolescence  risk  presented  by  each  assembly.  The  data 
elements  that  were  found  to  most  useful  in  characterizing  the  assembly  supportability 
issues  are: 

1)  Assembly  level  name,  typically  at  the  Lower  Replaceable  Unit  (LRU)  level 

2)  OEM  cage  code  and  name 

3)  OEM  part  number 

4)  Number  of  instances  the  LRU/assembly  is  used  in  the  system  under 
consideration. 
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5)  Mean  Time  Between  Failure  (MTBF),  this  is  an  OEM  supplied  number,  this 
number  is  necessary  in  calculating  the  required  number  of  spares  to  support  the 
system  under  consideration  for  a  given  length  of  time. 

6)  Cost  of  the  assembly 

7)  End  of  Production  (EOP)  date,  this  date  identifies  the  last  date  an  assembly  can 
be  manufactured  and  therefore  define  the  last  time  buy  date 

8)  End  of  Service  (EOS)  date,  this  date  identifies  the  last  date  an  assembly  can  be 
repaired  and  identifies  support  risks,  which  may  require  additional  procurement 
needs. 

9)  Forecasted  number  of  assemblies  needed  to  be  available  (purchased,  in  stock, 
etc.)  in  order  to  support  the  system  under  consideration  for  a  specified  length  of 
time. 

10)  Number  of  years  the  system  under  consideration  must  be  supported,  this  value 
is  usually  defined  by  the  PMO  or  by  the  program  support  team. 

The  characteristics  described  in  elements  1,2,  and  4  (see  above)  and  in  some  cases 
element  3,  are  extracted  from  the  COTS  list.  The  elements  described  in  5,  6,  7,  &  8  are 
provided  by  the  OEMs  and  require  direct  interface  to  obtain  the  information.  Item  9 
describes  values  which  are  calculated  and  are  based  on  the  nonnal  exponential 
distribution  of  failure  rates  expected  over  a  period  of  time  and  therefore  can  be  translated 
into  the  number  of  item  that  need  to  be  replaced  over  that  period.  The  last  item,  element 
10,  describes  the  number  of  years  the  fielded  system  is  expected  to  require  support  and  is 
usually  defined  by  the  PMO  as  the  interval  until  the  next  tech  refresh  date. 

Implementation  Experience: 

For  all  three  SSB  implementation  efforts  we  partnered  with  NSWC  Crane  and 
they  (Crane)  were  responsible  for  collecting  and  providing  the  above  data  elements.  The 
data  elements  collected  through  the  interfacing  with  the  OEMs  presented  some 
limitations  and  constraints  that  we  later  addressed.  The  two  elements  we  found 
inadequate  in  addressing  the  programs  requirements  were:  1 )  the  MTBF  numbers  were 
based  on  a  calculated  value  and  did  not  reflect  our  systems  fielded  environment,  and  2) 
the  forecasted  quantity  identified  only  the  mean  numbers  of  failures  or  50%  confidence 
level  whereas  the  program  support  team  desired  to  have  a  larger  variety  of  choices,  such 
as  75%  and  99%  confidence  levels  identifying  the  associated  replacement  buy  quantities. 
To  address  the  MTBF  issue  we  obtained  the  actual  MTBF  exhibited  by  our  fielded 
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systems.  This  data  was  provided  from  the  Material  Readiness  Data  Base  (MRDB)  at 
NSWC  Corona.  However,  because  the  description  of  the  assemblies  and  inconsistencies 
in  reported  indenture  levels,  our  data  request  did  not  correspond  with  the  data  entered 
into  the  database,  it  therefore  took  several  iterations  to  achieve  realistic  MTBF  numbers. 
Since  the  MTBF  number  defines  the  amounts  of  funding  and  budgeting  recourses  to  be 
used  in  future  years  it  is  critical  to  have  the  most  accurate  information  available.  To 
provide  the  most  accurate  data  possible  we  teamed  with  the  In  Sendee  Engineering  Agent 
(ISEA)  to  evaluate  the  MRDB  MTBF  numbers  then  provide  the  program  with 
recommendations.  Enclosure  (19)  -  Failure  Rate  Comparison  Table,  SSDS  MK1  - 
provides  an  example  in  which  we  were  able  to  compare  the  various  databases  with  the 
exhibited  failure  rate  seen  by  the  ISEA  when  servicing  the  fielded  equipment. 

Lessons  Learned: 

The  PMO  will  need  a  complete  description  of  how  the  assembly  quantities  were 
derived  and  the  distribution  of  those  forecasted  quantities,  along  with  their  relationship 
to  meeting  the  support  the  fielded  systems.  The  method  used  to  calculate  these  forecasted 
quantities  and  the  expected  distribution  over  a  given  time  period  is  defined  in  Enclosure 
(20)  -  Number  of  Spare  Parts  -  Cost  Justification  Matrix  -  in  a  word  document  and  the 
equations  are  embedded  in  the  Fcdlure  Rate  Comparison  Table,  Enclosure  (19).  These 
definitions  and  equations  provide  the  logical  methods  that  will  help  substantiate 
forecasted  quantities  which  the  PMO’s  decisions  will  based  on.  Your  understanding  of 
the  these  tools  and  adequate  justification  for  the  use  of  the  MTBF  numbers  that  are  used 
will  be  pivoted  in  the  PMO’s  decision  making  process. 

4.  Step  3.0  -  Prepare  Supportability  Risk  Report 

The  purpose  and  objective  of  this  step  in  the  process  is  to  summarize  and  report  to 
the  program  support  team  and  the  PMO,  the  supportability  risk  due  to  COTS  products  as 
evident  at  the  assembly  level.  This  high  level  summary  is  based  on  inputs  from  the 
OEMs  and  is  retrieved  through  phone  calls  to  the  Marketing  and  Sales  functions.  Due  to 
the  methods  in  acquiring  the  data,  the  data  has  limited  value  due  the  capricious  nature  of 
the  COTS  industry.  Although  the  data  is  not  as  solid  as  we  wish  it  could  be,  the 
information  gathered  can  help  in  planning  at  a  high  level,  particularly  if  the  data  reflects 
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the  current  technology  trends.  Usually  the  program  support  team  and  the  PMO  will  want 
to  review  and  buy-in  to  the  COTS  list  at  this  stage  of  maturity.  Enclosure  (21)  - 
Technology  Refresh  Cost  Model  Demo  -  provides  an  example  that  identifies  and  reports 
the  COTS  expected  life  cycle  and  potential  obsolescence  risk  at  the  assembly  level.  This 
presentation  was  prepared  by  NSWC  Crane  and  is  one  of  the  services  they  supplied  in 
evaluating  technology  trends.  One  of  the  most  useful  aspects  of  the  assembly  level  report 
is  the  identification  of  the  time  line  for  specific  assembly  that  shows  that  the  product  is 
scheduled  to  be  obsolete  in  a  particular  time  frame.  These  identified  assemblies  are 
potential  candidates  for  the  SSB  system  implementation. 

5.  Step  4.0  -  Identify  COTS  Assemblies  That  are  Appropriate  for  the 
SSB  System 

At  this  stage  in  the  process,  an  extensive  list  of  all  different  types  of  COTS 
products  may  be  incorporated  in  the  COTS  list.  Since  the  primary  characteristic  we  focus 
our  efforts  on  deals  with  microcircuits  due  to  the  high  obsolescence  risk  involved,  other 
non-microelectronic  based  products  can  be  eliminated  from  the  list.  The  filtered  list  will 
then  be  assessed  for  potential  SSB  system  implementation  candidates.  Typically  all 
assemblies  are  considered  potential  candidates  for  at  least  the  first  steps  of 
implementation  that  involves  establishing  a  working  relationship.  Removal  from  the 
candidate  list  at  this  point  in  the  process  is  accomplished  by  exception  only  basis, 
examples  of  such  exceptions  include:  the  company  is  in  financial  trouble  such  as 
“Chapter  11”,  the  assembly  under  consideration  has  a  direct  replacement  that  has  been 
tested  and  verified,  the  assembly  is  performing  poorly  in  the  application  and  under 
investigation.  Notional  consideration  is  given  to  the  potential  OEM  candidates  and  if  an 
appropriate  SSB  supplier  exists  to  partner  with  them  or  if  the  OEM  already  has  partnered 
with  an  SSB  supplier. 

6.  Step  5.0  -  Contact  OEM  &  SSB  Supplier  Candidates  - 

Initial  contact  with  the  OEMs  and  interfacing  with  the  SSB  supplier  candidates  is 
perhaps  one  of  the  most  unique  aspects  embedded  within  the  SSB  system  because  the 
interchange  of  information  between  yourself  and  the  OEM  can  be  extensive.  From  the 
implementers  perspective  it  is  important  that  the  OEM  understands  the  basic  concepts 
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behind  the  SSB  system  and  the  critical  nature  of  the  OEM’s  participation  in  the  system. 
As  a  receiver  of  information  from  the  OEM  the  implementer  must  get  an  understanding 
of  the  OEM’s  business  environment,  current  policies  and  practices,  and  how  the  SSB 
system  can  be  implemented  through  the  OEM.  The  OEM  will  need  to  receive  some 
logical  reasons  to  peruse  the  potential  implementation  and  have  some  kind  of  business 
case  to  justify  such  an  effort.  In  most  cases  we  found  that  initial  contact  over  the  phone, 
required  follow-up  actions  such  as  emails  documenting  the  concept  and  eventually  a  visit 
to  the  OEM’s  facility  to  present  the  concept  in  detail.  The  information  regarding  each 
company  and  all  the  configurations  under  consideration  is  extensive  and  will  get 
confusing  unless  it  is  organized  in  a  methodical  way  and  the  records  are  updated 
regularly  and  consistently.  The  example  provided  in  Enclosure  (15)  -  SSDS  MK  1&2 
prioritized,  COTS  list,  illustrates  the  method  that  was  used  during  the  implementation 
process  for  the  SSDS  programs.  Key  infonnation  provided  in  this  matrix  is  typically 
needed  during  almost  every  contact  with  the  potential  candidates.  The  matrix  also  has 
columns  to  annotate  information  already  gathered  and  actions  yet  to  be  taken.  In  essence 
the  matrix  is  used  much  like  a  sales  persons  contact  list  in  providing  important 
information  that  is  continuously  updated  to  reflect  the  ongoing  communication  with  the 
customer.  The  objective  in  this  step  is  to  orchestrate  the  situation  such  that  the 
representatives  of  the  OEM,  gain  a  comfort  level  with  the  SSB  system  concepts  so  that 
they  feel  they  can  endorse  the  company’s  involvement.  If  this  level  of  comfort  is 
achieved  and  if  the  decision  makers  were  the  ones  you  had  presented  to,  the  next  steps  in 
the  process  are  usually  completed  immediately.  However,  if  the  decision  makers  were 
not  present  and  the  receiving  individuals  must  check  with  their  proper  authority,  they 
may  act  as  your  ambassador  or  ask  you  to  return  and  present  to  the  actual  decision 
makers.  If  asked  to  return  and  present  to  the  decision  makers,  our  experience  shows  us 
that  in  every  instance  of  a  return  visit,  the  company  will  chose  to  participate. 

Implementation  Experience: 

During  implementation  we  found  this  step  was  a  people  orientated  and 
communication  intensive  where  the  discussions  were  very  interactive  requiring  us  to 
“think  our  way  through  ”  conversations  instead  of  pre-planed  responses.  In  contrast  to 
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the  conversations,  the  travel  arrangements  and  meeting  appointments,  at  times,  required 
artful  mastery  of  visiting  4  states  in  4  days,  attempting  to  keep  within  the  closest 
geographical  areas  as  possible.  What  made  the  arrangements  so  interesting  is  that  the 
availability  of  the  OEMs  personnel  dictated  the  planning  and  each  OEM  would  make 
visit  arrangements  based  on  their  constraints.  The  scheduling  and  planning  skill  to 
optimize  the  travel  required  to  the  OEMs  constraints  while  meeting  the  programmatic 
constraints  placed  on  anyone  implementing  this  step  of  the  process  will  be  challenging. 

Lessons  Learned: 

An  excellent  tool  to  help  with  producing  productive  communication  to  enable 
success  for  this  step  of  the  process  is  to  leverage  off  of  past  conversations  by  keeping  a 
running  log  of  previously  asked  questions  and  answers.  This  log  will  never  be  complete 
but  its  use  is  to  provide  consistency  and  completeness.  In  arranging  visits  to  the  OEMs  it 
is  very  helpful  to  group  the  OEMs  by  geographical  area  then  prioritize  within  that  area 
each  OEM.  This  type  of  grouping  will  help  coordinate  the  decision  making  process  for 
travel  arrangements. 

7.  Step  6.0  -  Parts  List  from  OEM  Received  -  Analysis  &  Obsolescence 
Report 

Receiving  the  assembly  component  piece  part  lists  represents  one  of  the  most 
significant  steps  in  the  entire  process.  Establishing  the  relationship  between  the  OEMs 
and  the  program  needs,  can  now  show  tangible  results  through  sharing  of  the  OEM’s 
intellectual  property.  It  is  important  to  review  why  these  piece  part  lists  are  so  essential 
to  the  obsolescence  risk  management  process  used  in  the  SSB  system.  The  COTS 
products  are  designed  into  our  fielded  systems  based  solely  on  their  performance 
characteristics  at  the  assembly  level.  The  prime  contractor/PMO  does  not  pay  for  the 
intellectual  data  rights  for  the  COTS  products.  The  developmental  cost  associated  with 
these  products,  are  paid  for  by  the  OEMs  and  they  control  the  configuration  management 
and  manufacturing  processes.  Only  at  the  assembly  level  will  the  OEM  be  responsible  to 
the  customer  (the  prime  contractor/PMO)  in  assuring  repeatable  performance  in  systems 
designed  with  the  COTS  product.  Given  this  scenario  the  obsolescence  risk  experienced 
by  the  PMO  is  at  the  assembly  level  where  interoperability  and  integration  impacts  can  be 
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complex  and  expensive  to  resolve.  In  receiving  insight  into  the  assembly  through  the 
component  piece  part  lists,  we  have  for  the  first  time  the  ability  to  mitigate  the 
obsolescence  risk  at  the  piece  part  level.  In  resolving  the  risk  at  this  lower  level,  the 
remedy  cost  will  be  much  less  due  to  the  cheaper  cost  of  the  piece  parts  and 
circumventing  the  potential  impacts  to  integration  and  interoperability.  Therefore  by 
obtaining  the  component  piece  part  lists  we  are  now  able  to  manage  the  PMO’s  risk  at  the 
most  cost  effective  and  efficient  level.  In  working  through  this  part  of  the  process  a  Non 
Disclosure  Agreement  (NDA)  is  usually  signed  by  both  parties  to  protect  the  intellectual 
property  from  distribution  beyond  the  intended  application  as  part  of  the  SSB  system. 
Enclosure  (5)  provides  a  general  fill-in-the  blank  template  NDA  form  however  most 
companies  already  have  a  standard  NDA  form  that  they  prefer  to  use.  The  NDA 
formalizes  the  OEMs  buy-in  of  the  SSB  system  and  has  prepared  the  way  for  the  transfer 
of  the  intellectual  property. 

Once  received,  the  component  piece  part  lists  must  be  translated  into  usable 
information  before  analysis,  evaluation,  and  recommendations  can  be  accomplished.  The 
transfer  process  of  the  component  piece  part  lists  (hereafter  referred  to  as  -  the  parts  list) 
will  take  many  forms  and  be  dependent  on  the  OEM’s  business  practices.  The  parts  list 
may  be  provided  via  a  web  site,  a  fax,  an  email,  or  in  paper  hard  copy  fonn.  In  an  effort 
to  reduce  the  amount  of  work  necessary  to  handle  these  parts  lists  we  developed  a 
preferred  format  that  is  supplied  to  potential  OEMs.  Enclosure  (22)  -  Requested  Format 
for  Parts  Lists  -  identifies  this  preferred  format  but  cannot  be  required  since  we  need  to 
work  within  the  OEM’s  standard  business  practices.  Regardless  of  which  format  the 
parts  lists  are  received  in,  we  will  need  to  filter  out  non  microelectronic  parts  and 
specially  fonnat  it  so  that  it  can  be  downloaded  to  the  server  database.  When  the 
formatting  and  filtering  is  complete  the  parts  lists  will  need  to  be  evaluated  for 
obsolescence  risk  of  each  component  piece  part  on  the  list.  Although  there  are  many 
commercial  services  and  industry  standard  tools  to  perform  this  function  we  chose  to 
partner  with  another  field  activity  who  performed  this  task.  Our  method  for  handling  the 
parts  lists  at  this  stage  in  the  process  was  to  email  the  list  to  NSWC  Crane  and  once  the 
evaluation  and  analysis  was  complete  it  was  emailed  back  to  NSWC  Corona.  NSWC 
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Crane  provided  excellent  service  and  when  problems  occurred,  they  worked  with  us  to 
resolve  every  issue.  The  parts  lists  came  in  from  the  different  OEMs  at  various  times 
depending  on  the  time  of  interface  with  the  OEM  and  the  response  time  from  the  OEM. 
The  progression  through  this  process  was  monitored  through  the  use  of  a  status  matrix 
described  in  Enclosure  (23)  -  Vendor  Status  Report.  This  status  matrix  was  updated  on  a 
weekly  basis  and  reported  to  the  program  support  IPT  as  requested.  On  an  annual  basis 
or  as  requested  by  the  PMO,  the  detailed  information  on  all  assemblies  in  the  SSB  system 
pertaining  to  a  specific  program  are  assembled  into  a  single  document  and  provided  to 
that  program  as  a  SSB  system  update.  Enclosure  (24)  -  Obsolescence  Health  Report  is 
the  SSDS  example  of  such  a  report.  These  reports  are  extensive  since  the  following 
information  is  provided:  the  status  of  the  SSB  system  implementation,  the  assemblies 
obsolescence  health  arranged  per  system  indenture,  a  summary  report  of  obsolete 
component  piece  parts  (Red,  high  risk  values),  graphical  depiction  of  the  obsolescence 
health  analysis,  and  executive  summary  for  the  system.  The  fonnat  and  detail  is 
dependent  on  the  request  or  needs  of  the  specific  program,  so  before  arbitrarily  adopting 
the  example  format  we  suggest  interfacing  with  your  program  before  proceeding. 

8.  Step  7.0  &  8  -  PMO  Review  &  Approval  of  Obsolete  Component 
Parts  Purchase  Request  /  Procurement  Support  Prepares  Purchase 
Order  of  Obsolete  Component  Parts  - 

One  of  the  products  of  the  preceding  step  is  a  list  of  red  coded  piece  parts 
identifying  them  a  high  obsolescence  risk  items.  Enclosure  (25)  -  SSDS  Red  Component 
List  provides  an  example  of  such  a  list.  These  specific  parts  have  been  discontinued  and 
soon  will  not  be  available  for  purchase.  Our  experience  has  shown  that  the  availability  of 
a  part  in  the  open  market  after  the  production  has  stopped  is  about  8  to  12  months,  this 
time  lag  before  all  parts  are  bought  up  is  referred  to  as  the  ‘Grey  Market.’  It  is  important 
to  purchase  the  obsolete  parts  while  still  in  the  early  stages  of  the  Grey  Market  because  a 
$20.00  part  can  raise  in  value  to  a  $2500.00  part  as  the  component  becomes  scarce.  The 
purchase  of  Grey  Market  parts  will  continue  to  be  an  ongoing  function  as  new  high-risk 
parts  are  identified.  Depending  on  the  impact,  both  risk  and  financial,  the  purchase  of 
obsolete  parts  may  be  as  simple  as  an  email  form  (see  Enclosure  (26))  or  as  fonnal  as  a 
detailed  report.  Enclosure  (27)  -  Analysis  of  Intel’s  i680  obsolescence  on  OEM  products 
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-  SSDS  program  -  is  a  good  example  of  how  to  structure  a  detailed  impact  and  purchase 
request  due  to  obsolescence.  It  will  be  important  to  automate  this  process  as  much  as 
possible  because  there  will  be  a  continuous  stream  of  these  requests  over  the  years  the 
programs  system  need  to  be  supported.  Step  8  is  included  with  step  7  because  after  the 
approval  for  the  request  is  given  (step  7)  the  approved  request  is  passed  onto  the 
procurement  activity  to  translate  it  into  a  Purchase  Order  to  the  SSB  supplier.  In  turn  the 
SSB  supplier  will  receive  the  Purchase  Order  and  go  out  to  the  open  market  and  procure 
the  obsolete  parts  subsequently  storing  them  at  their  facility.  This  action  of  storing  parts 
on  the  SSB  suppliers  shelves  can  take  place  immediately  if  the  OEM  agrees  to  take  on  the 
role  of  being  its  own  SSB  supplier.  Our  experience  has  shown  that  over  90%  of  the 
OEMs  wish  to  implement  using  this  method.  With  the  in-house  SSB  relationship  at  the 
OEM,  technology  transfer  is  not  an  issue  and  there  is  no  real  impact  to  current 
procurement  arrangements.  However  if  the  OEM  chooses  to  transfer  their  technology  to  a 
third  party  SSB  supplier,  storage  of  procured  part  will  usually  need  to  take  place  after 
steps  9.0-13.0  are  completed. 

9.  Steps  9.0  -  13.0  -  Technology  Transfer  Roadmap  - 

Each  of  the  steps  described  below  are  for  the  general  case  and  of  notional  value 
only.  However  the  process  flow  is  provided  as  a  guideline  of  major  stages  in  the 
technology  transfer  process  and  can  be  used  by  the  SSB  system  implementer  as  the 
identifiable  stages  to  monitor.  All  five  of  these  stages  are  accomplished  by  the  OEM  and 
the  SSB  supplier  when  intellectual  property  is  transferred.  This  process  is  formalized 
through  a  binding  contract  between  the  OEM  and  the  SSB  supplier  and  completion  of  the 
process  is  as  agreed  upon  by  these  two  entities.  The  role  the  SSB  system  implementer 
plays  in  this  process  is  to  monitor  the  progress  to  assure  availability  of  parts  when  needed 
by  the  program.  A  note  of  caution  with  regard  to  the  technology  transfer  process:  if  you 
as  the  implementer  have  not  had  experience  performing  the  tasks  described  below  and  are 
asked  to  help  implement  the  transfer  process  be  extremely  careful  because  this  process  is 
tricky  and  very  difficult  to  perform  successfully.  There  are  internal  Navy  assets  (NSWC 
Corona  &  NSWC  Crane)  to  help  you  accomplish  this  task  and  mentor  you  through  the 
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process,  so  if  you  need  the  help  ask  for  it.  Short  descriptions  of  each  of  the  major 
technology  transfer  stages  are  as  follows: 

a.  9.0  Business  &  Legal  Documentation  in  Place 

Development  of  the  contract  language,  terms  and  conditions,  methods  and 
processes  for  reporting,  payment  of  royalties,  expectation  of  business  structures  and 
handling  of  Intellectual  Property  rights  are  some  of  the  more  important  issues  covered. 
The  only  input  the  SSB  implementer  should  have  in  this  stage  is  to  ask  that  a  clause  be 
placed  in  the  contract  to  allow  a  third  party  to  obtain  a  component  piece  parts  list  of  each 
assembly  to  assess  the  obsolescence  risk. 

b.  10.0  Transfer  Technology  to  SSB  Supplier  from  OEM 

Typically  the  two  companies  will  handle  this  process  between  themselves 
however  on  occasion  to  enhance  communication  or  facilitate  the  transfer  one  or  both 
companies  will  ask  for  participation  from  the  SSB  implementer.  If  this  happens  be 
careful  if  you  become  involved,  you  carry  no  contractual  weight  and  must  stay  at  a 
distance  if  a  dispute  occurs.  A  good  implementer  is  invaluable  during  this  process  so  if 
you  need  help  ask  for  it.  During  this  stage  the  implementer  is  there  to  monitor  progress 
and  enable  the  process  but  not  become  embroiled  in  disputes  between  the  primary  parties. 

c.  11.0  -  Perform  Pre-Production  Readiness  Review 

This  function  will  be  performed  by  the  OEM  with  the  possibility  of  the 
SSB  implementer  present  as  a  casual  observer.  The  implementer’ s  function  here  is  to 
monitor  and  observe. 

d.  12.0  -  SSB  Supplier  Production  of  First  Piece 

Evaluation  of  first  piece  production  is  a  standard  industry  practice  to 
assure  the  quality  of  the  production  processes,  methods  and  practices  have  been 
adequately  transferred.  This  quality  function  is  perfonned  by  the  OEM.  The 
implementer’ s  function  here  is  to  monitor  and  observe. 
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e.  13.0  -  OEM  Performs  Quality  Verification  Testing  of  First  Piece 

The  verification  testing  of  the  first  piece  of  production  is  different  from 
the  previous  evaluation  in  that  it  is  a  process  control  for  the  adequacy  of  the  testing 
methods  and  equipment.  When  possible  the  OEM  will  use  the  original  test  equipment  at 
their  facility  to  cross  check  the  SSB  suppliers  test  set  up.  Again,  the  implementer’s 
function  here  is  to  monitor  and  observe. 

10.  Steps  14.0  &  15.0  -  SSB  Supplier  Full-Scale  Production  /  Assess 
Government  Assets- 

Although  there  are  two  primary  paths  to  get  to  this  point  in  the  process  -  to  sunset 
the  technology  within  the  OEM’s  facility  or  to  transfer  the  technology  to  a  third  party 
SSB  supplier  -  the  end  result  should  be  the  same.  Once  the  SSB  system  is  in  place 
within  a  production  facility  there  will  be  three  ongoing  requirements  for  which  the  SSB 
system  implementer  will  participate  in.  The  first  of  these  requirements  is  the  ongoing 
evaluation  of  the  component  piece  part  obsolescence  risk  assessment  and  the  subsequent 
purchase  requests  for  new  obsolete  parts.  The  second  function  in  which  the  SSB 
implementer  participates  in  is  the  independent  assessment  and  reporting  of  Navy  assets 
on  hand  at  the  SSB  supplier.  This  assessment,  required  is  by  the  Federal  Acquisition 
Regulation  (FAR)  to  be  done  annually  at  a  minimum.  The  third  function  is  actually 
performed  by  the  SSB  implementer  or  a  designee,  and  requires  them  to  assess  the  health 
of  the  SSB  supplier  using  tools  similar  to  the  IEEE  1722  evaluation  matrix  which  is  an 
industry  “Best  Practice”  evaluation  tool.  This  annual  assessment  will  focus  on  the  overall 
health  of  the  SSB  supplier  covering  the  following  major  areas:  financial,  technical 
capability,  technical  support,  materials  and  configuration  controls,  past  perfonnance  data 
and  cost  containment  or  growth. 

11.  Steps  16.0  &  17.0  -  Ordering  and  Shipping  of  Assemblies  - 

The  SSB  system  has  been  designed  to  work  within  current  Navy  procurement 
structures  in  support  of  the  Navy  Procurement  System  (NAVICP)  and  directly  to  the  end 
user  if  that  path  has  been  already  defined.  The  one  issue  the  SSB  implementer  must 
address  is  that  if  a  third  party  SSB  supplier  has  been  brought  into  the  situation,  then  an 
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alternate  cage  code  for  the  sunset  item  needs  to  be  generated.  This  alternate  cage  code 
allows  the  procurement  system  to  purchase  directly  from  the  new  source. 
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IV.  SECTION  3:  MEASURING  &  ASSESSING  THE  SSB 

SYSTEM: 


This  final  section  of  the  SEDI  plan  identifies  methods  and  metrics  to  measure  the 
impact  of  implementing  a  SSB  system,  thereby  providing  adequate  indicators  for  the 
programs  to  assess  the  effectiveness  and  value  proposition  in  using  the  system. 
Implementation  and  establishment  of  a  SSB  system  can  be  partitioned  into  three  separate 
measurement  areas  that  necessitate  the  use  of  different  measurement  or  assessment  tools 
in  each  area.  The  first  measurement  area  involves  the  assessment  of  the  relationship 
between  the  OEMs/SSB  suppliers  and  the  implementing  program.  The  second  set  of 
measurements,  deals  with  the  data  extraction  and  information  transfer  tasks  such  items  as 
transfer  of  component  piece  part  lists  -  transferring  and  assessment.  The  final  area  of 
interest  for  measurement  and  assessment  is  the  transfonnation  of  the  collected  data  into 
support  criteria  directly  applicable  to  the  PMO  supportability  planning.  Each  of  these 
areas  requires  different  types  of  metrics  and  all  areas  are  measured  concurrently  to 
achieve  a  robust  assessment  of  the  COTS  obsolescence  risk.  Continuous  and/or  periodic 
monitoring  in  all  three  areas  is  encapsulated  as  part  of  the  SSB  system  design. 

Relationship  building  and  partnering  with  the  supplier  base  is  a  value  added 
function  for  the  PMO  in  defining  opportunity  and  managing  risk.  The  risk  management 
aspects  of  effort  extend  beyond  just  obsolescence,  many  other  types  of  risks  must  be 
evaluated  such  as:  financial  risk  -  is  the  supplier  financially  solvent,  business  risk  -  how 
are  mergers  going  to  effect  the  support  efforts,  business  planning  risks  -  what  do  future 
business  opportunities  look  like  and  with  that  knowledge  is  the  company  willing  to 
support  the  PMO’s  program,  perception  risk  -  is  the  company  perceived  as  supportive  or 
are  there  negative  connotations  associated  with  the  company.  Identifying  and  assessing 
these  kinds  of  risks  are  part  of  the  relationship  building  process  and  these  types  of  issues 
need  to  documented  and  reported.  The  program  will  want  to  know  this  information  and 
also  the  subjective  risk  assessment  as  perceived  by  the  SSB  system  implementer  and 
potential  impacts  to  the  program.  During  our  implementation  efforts  we  instituted  two 
standard  methods  to  document  the  relationship  and  partnering  information  we  gathered. 
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In  an  effort  to  document  the  information  obtained  through  interfacing  with  the  OEM/S  SB 
suppliers  we  instituted  the  SSDS  MK  1&2  prioritized,  COTS  list.  Enclosure  (15) 
provides  an  example  of  the  list  in  the  early  stages  of  maturity.  The  list  contains  basic 
information  about  the  OEM,  points  of  contact,  assembly  configurations  of  interest,  and 
approximate  quantities.  The  utility  of  the  list  is  greatly  enhanced  by  the  additional 
columns  that  describe  implementation  details,  company  and  product  information,  and  the 
ongoing  list  of  actions  to  be  taken  by  the  company  and  by  the  implementer.  The 
information  documented  in  this  manner  was  extremely  useful  during  program  reviews  in 
addressing  or  raising  risk  issues.  We  continually  shared  this  contact  list  with  the  entire 
program  support  team.  Although  not  quantitative  in  nature,  this  risk  reporting  devise 
received  the  team’s  endorsement  as  a  good  communication  tool.  Another  use  for  the  list 
was  developed  to  communicate  the  most  current  state  of  the  relationship  building  efforts 
and  then  provide  recommendations  to  the  PMO  in  support  of  a  Funding  Allocation 
Review  (FAR)  decision-making  process.  Enclosure  (16)  -  SSDS  MK  1&2  prioritized, 
COTS  list,  Budget  support:  illustrates  how  the  various  descriptions  and  assessment  of 
risk  are  combined  in  support  of  a  recommendation  to  the  PMO.  In  conjunction  with  the 
contact  list  another  tool  was  developed  to  provide  the  program  support  team  and  the 
PMO  with  insight  to  the  SSB  system  implementation  process.  This  insight  was 
documented  in  a  matrix  that  related  the  specific  OEM  assembly  configurations  to  the  “17 
Step”  implementation  process.  This  matrix  provides  an  implementation  assessment  in 
easily  interpreted  graphical  format  that  represents  a  snapshot  of  “work  in  progress”. 
Enclosure  (23)  -  Vendor  Status  Report  -  is  an  example  of  a  status  report,  which  was 
generated  for  the  SSDS  MK1  program.  This  report  was  very  useful  in  communicating  to 
all  involved  parties  the  progress  of  the  implementation  efforts.  Another  assessment  tool 
currently  under  development  is  an  assessment  tool  for  evaluating  the  SSB  supplier  ability 
to  maintain  continued  support  year  to  year.  The  tool  is  based  on  the  IEEE  1722 
assessment  matrix,  which  is  an  industry  standard  for  perfonning  these  types  of 
evaluations. 

The  second  set  of  measurements  involves  the  transferred  information  gathered 
from  the  OEMs  and  subsequent  evaluation  and  analysis  of  that  infonnation,  as  a  result  of 
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the  implementation  process.  This  set  of  tools  yields  objective  and  quantifiable 
obsolescence  risk  assessment  of  the  COTS  products  used  in  the  fielded  hardware. 
Individual  assembly  assessments  are  combined  in  an  indentured  approach  modeling  the 
fielded  system’s  configuration.  The  assessments  are  then  rolled  up  to  the  next  level  of 
indenture  and  finally  to  the  system  level.  An  obsolescence  health  assessment  is  identified 
at  each  level  of  indenture.  Other  salient  data/information  is  provided  to  provide  context 
to  the  analysis  being  reported.  Enclosure  (24)  -  Obsolescence  Health  Report  -  is  a  report 
submitted  for  the  SSDS  MK1  program  and  provides  an  example  on  how  to  illustrate  the 
combined  analysis  efforts  to  communicate  to  the  PMO  the  assessed  system  obsolescence 
risk  due  to  COTS  products.  An  extract  from  this  report  identifies  the  component  piece 
parts  that  represent  a  high  obsolescence  risk  -  RED  Coded  parts.  Enclosure  (25)  -  SSDS 
Red  Component  List  -  is  an  extract  from  both  MK1  &  MK2  systems  and  provides  an 
example  to  illustrate  the  immediate  treat  to  the  program’s  ability  to  support  the  fielded 
systems.  The  format  and  content  of  these  types  of  reports  are  highly  dependent  on  the 
PMO’s  needs  and  desires  therefore  the  subject  should  be  negotiated  prior  to  the 
development  of  the  report. 

The  last  area  of  measurement  and  assessments  is  the  ‘Capstone’  of  the  entire  SSB 
system’s  implementation  effort.  It  brings  together  all  the  information  and  data  collected 
and  provides  functionality  previously  unattainable  without  the  SSB  system  -  Systems 
Engineering  approach.  The  ‘Capstone’  assessment  tool  is  illustrated  in  Enclosure  (28)  - 
SSDS  Assembly  Master  &  Cost  Matrices.  Every  tool,  method,  and  process  developed  to 
implement  the  SSB  system  is  either  directly  or  indirectly  responsible  for  the  numbers 
evident  in  the  matrices.  Enclosure  (29)  -  SSB  Planning  Excel  Workbook  &  Data  Item 
Description  -  provides  detailed  explanations  for  the  descriptions  of  each  cell  along  with 
the  mathematical  relationships  and  constraints  implemented  within  the  worksheet. 
Important  to  understand  that  without  implementing  the  SSB  system  the  options  are 
limited  to  Life  of  Type  Buy  (LTB)  or  Other  -  an  identifier  for  options  which  are  typically 
resource  intensive,  cause  changes  to  the  configuration  baseline  that  cause  perturbations  in 
the  support  structures,  or  are  limited  in  scope  to  specific  situations  unique  to  the 
application.  Only  the  SSB  system  provides  a  systematic  process  to  adjust  to  budget 
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constraints  while  providing  the  highest  level  of  supportability  possible.  The  matrices  are 
defined  with  built  in  algorithms  that  allow  the  user  to  perfonn  “What  if’  scenarios  so  that 
the  most  optimum  practical  support  approach  can  be  developed.  The  most  important 
metrics  from  the  PMO  perspective  are  the  cost  numbers  given  different  alternatives  and 
the  inherent  risk  associated  with  those  figures.  The  cost  matrices  tool  gives  the  PMO  the 
capability  to  model  and  simulate  prior  to  making  decisions  and  when  combined  with  new 
support  options  available  through  the  SSB  system  increases  the  probability  of  success  in 
long  term  supportability  of  the  fielded  systems. 
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ABSTRACT 


This  Business  Case  Analysis  (BCA)  is  one  of  the  four  foundational  documents 
created  to  establish  the  Sunset  Supply  Base  system  as  a  Commercial  off  the  Shelf 
(COTS)  supportability  alternative  for  Navy  fielded  systems  containing  COTS  products. 
This  BCA  focuses  on  the  Sunset  Supply  Base  system  for  supporting  Commercial  Off  The 
Shelf  (COTS)  products  as  they  are  used  in  the  Ship  Self-Defense  System  (SSDS)  MKI. 
The  Sunset  Supply  Base  (SSB)  concept  is  intended  to  extend  the  supportability  of  COTS 
products  used  in  Navy  weapon  system  programs.  This  BCA  will  consider  the 
consequences  of  implementing  the  SSB  infrastructure  for  providing  COTS  support  for 
the  SSDS  program.  These  consequences,  which  will  include  both  tangible  and  intangible 
results,  will  be  analyzed  for  confonnance  to  DoD  policy,  program  requirements  and 
overall  cost/benefit.  Furthermore,  it  will  look  at  how  well  the  actual  implementation 
relates  to  the  goals  and  objectives  of  the  SSB.  In  short,  this  business  case  will  examine 
the  likely  costs  and  benefits  that  will  result  in  implementing  the  SSB  system  for 
supporting  the  SSDS  program. 


The  nature  of  the  SSB  thesis  topic  and  the  approach  taken  by  the  authors  necessitated  the 
use  of  examples,  templates,  tools,  methods,  and  practices.  These  implementation  tools 
and  deliverable  products  are  illustrated  through  a  set  of  enclosures  referenced  in  the 
thesis  and  its  appendices.  Most  of  the  enclosures  are  static  examples  generated  during 
the  implementation  of  the  SSB  system  on  three  Navy  programs.  However,  other 
enclosures  are  not  static  and  are  therefore  provided  on  a  web  site  (URL: 
http://www.anavision.org/ssb.htm  )  in  the  Excel  format  to  provide  a  dynamic  model  for 
use  by  an  implementer  of  the  SSB  system. 
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I.  EXECUTIVE  SUMMARY 


This  Business  Case  Analysis  (BCA)  focuses  on  the  Sunset  Supply  Base  concept  for 
supporting  Commercial  Off  The  Shelf  (COTS)  products  as  they  are  used  in  the  Ship  Self-Defense 
System  (SSDS)  MKI.  The  Sunset  Supply  Base  (SSB)  concept  is  intended  to  extend  the 
supportability  of  COTS  products  used  in  Navy  weapon  system  programs.  The  concept  is  unique 
in  that  it  takes  an  After  Market  approach  to  supporting  COTS  due  to  Original  Equipment 
Manufacturer  (OEM)  discontinuation  of  items  presently  or  planned  to  be  used  in  Navy  weapon 
systems.  The  Sunset  Supply  Base  concept  offers  a  support  infrastructure,  which  may  include 
third  party  support  to  bridge  the  gap  between  industry  business  objectives  and  the  Navy’s 
requirement  for  long-term  system  support. 

The  current  DoD  requirements  include  a  scenario  of  increased  operations  while  at  the 
same  time  a  continuous  push  for  weapon  system  upgrades.  Given  the  present  pressures  for 
reducing  costs,  DoD  Program  Management  Offices  (PMO)  are  challenged  to  search  for  more 
economical  alternatives.  The  challenge,  in  effect,  is  to  maintain  near-term  weapon  system 
readiness  while  at  the  same  time  planning  for  weapon  system  modernization  efforts. 
Furthermore,  technology  evolution  is  being  driven  by  the  commercial  sector  and  no  longer  by  the 
DoD.  The  DoD  looks  to  the  commercial  sector  for  technology  concepts  to  transfer  to  their 
warfighter.  As  a  result,  the  DoD  has  established  a  COTS  initiative  to  deliver  state-of-the-art 
technology  to  the  warfighter  faster  and  cheaper.  The  emphasis  on  COTS  product  usage  was 
brought  on  by  the  fact  that  the  DoD  could  conceivably  take  advantage  of  technology 
developments  in  the  commercial  sector  at  a  reduced  cost  to  development  programs.  With  COTS 
products  come  additional  challenges  in  support,  given  the  fast  paced  technology  update  cycles  in 
the  commercial  sector  as  compared  to  the  slow  and  methodical  DoD  acquisition  processes.  Thus, 
there  is  an  anticipated  increase  in  material  or  product  obsolescence.  Presently,  the  commercial 
sector  has  technology  refresh  cycles  of  18-24  months[l)  Glum,  2)  Robinson,  3)  McDermott], 
after  which  time  the  product  is  typically  discontinued.  The  DoD  on  the  other  hand  takes  a 
purposely  conservative  and  methodical  approach  in  terms  of  planning  and  budgeting. 
Additionally,  the  DoD  design,  develop  and  implementation  process  typically  exceeds  5  years. [3) 
McDermott]  This  misalignment  has  lead  to  significant  challenges  in  maintaining  system  baseline 
stability.  There  is  also  little  incentive  for  the  Original  Equipment  Manufacturers  (OEMs)  to 
accommodate  the  DoD  requirements  since  the  DoD  only  makes  up  roughly  0.4%  of  the  market 
share.  [1)  Glum,  2)  Robinson,  4)  Flartshom] 
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To  address  these  issues,  this  document  establishes  specific  goals  and  objectives  for  the 
SSB  system  and  then  through  careful  and  thorough  analysis,  derives  benefits  for  alignment  with 
current  Naval  business  needs.  Based  on  this  alignment  we  advocate  the  implementation  of  the 
SSB  architecture  to  provide  dependable,  cost  effective  supportability  insurance  for  COTS  based 
weapon  systems.  The  SSB  process  focuses  on  obsolescence  issues  and  material  shortages 
associated  with  COTS  usage  in  military  weapon  and  support  systems.  Addressing  these  specific 
areas,  the  SSB  provides  an  opportunity  to  extend  COTS  supportability  in  an  effort  to  stabilize  the 
weapon  system  baseline.  Generally  speaking,  the  purpose  here  is  to  show  how  the  SSB  system 
meets  the  needs  and  expectations  of  the  Navy’s  acquisition  process  by  evaluating  its 
implementation  on  the  SSDS  MKI  program.  The  period  of  analysis  is  between  fiscal  year  2003 
and  2012.  The  data  obtained  for  this  case  study  was  collected  in  FY  2002  and  applies  to  SSDS 
MKI  program  execution  beginning  in  FY2003. 

The  results  presented  in  the  Analysis  section  of  this  document  illustrate  how  the  SSB 
implementation  provides  significant  cost  savings  to  the  SSDS  MKI  program  in  terms  of  total 
support.  Furthermore,  this  Business  Case  Analysis  also  demonstrates  how  the  SSB  infrastructure 
is  an  affordable  approach  for  mitigating  program  supportability  risk  and  can  directly  support 
other  existing  combat/weapon  systems.  To  this  end,  it  provides  the  PMO  an  additional  support 
solution  alternative  for  meeting  the  challenge  of  maintaining  weapon  system  readiness  and 
warfighter  requirements  in  the  most  cost  effective  method  possible. 

The  nature  of  the  SSB  thesis  topic  and  the  approach  taken  by  the  authors  necessitated  the 
use  of  examples,  templates,  tools,  methods,  and  practices.  These  implementation  tools 
and  deliverable  products  are  illustrated  through  a  set  of  enclosures  referenced  in  the 
thesis  and  its  appendices.  Most  of  the  enclosures  are  static  examples  generated  during 
the  implementation  of  the  SSB  system  on  three  Navy  programs.  However,  other 
enclosures  are  not  static  and  are  therefore  provided  on  a  web  site  (URL: 
http  ://www.  anavision.org/ssb  .htm  )  in  the  Excel  format  to  provide  a  dynamic  model  for 
use  by  an  implementer  of  the  SSB  system. 
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II.  OVERVIEW 


A.  SUBJECT  STATEMENT 

1.  The  Sunset  Supply  Base  System 

This  Business  Case  Analysis  (BCA)  focuses  on  the  Sunset  Supply  Base  concept 
for  supporting  Navy  hardware  that  incorporates  the  use  of  Commercial  Off  The  Shelf 
(COTS)  products.  The  Sunset  Supply  Base  (SSB)  concept  is  intended  to  extend  the 
supportability  of  COTS  products  used  in  Navy  weapon  system  programs.  The  concept  is 
unique  in  that,  it  takes  an  After  Market  approach  to  supporting  COTS  due  to  Original 
Equipment  Manufacturer  (OEM)  discontinuation  of  items  presently  or  planned  to  be  used 
in  Navy  weapon  systems.  OEMs  routinely  drop  a  product  line  or  significantly  modify  a 
product  as  technology  moves  forward.  Discontinuation  or  revision  to  a  product  is  based 
solely  on  the  business  case  for  that  product  and  when  the  business  case  can  no  longer 
support  production  the  product  is  discontinued,  regardless  of  the  impact  to  the  DoD/Navy 
(the  DoD  makes  up  only  .4%  of  the  market.[l)  Glum,  2)  Robinson,  4)  Hartshorn]) 
Typically  this  occurs  at  approximately  18-months  to  2-year  intervals. [3)  McDermott], 
As  these  COTS  items  become  obsolete,  the  DoD/Navy  weapon  system  baseline 
configuration  becomes  unstable  during  periods  of  time  between  scheduled  technical 
refresh  and  insertion.  This  BCA  will  provide  greater  detail  as  to  why  this  occurs  but  for 
the  immediate  discussion  it  would  serve  to  briefly  describe  the  circumstances 
surrounding  this  phenomenon. 

The  OEMs  are  market  driven  enterprises.  They  rely  on  high  technology,  high 
volume  and  their  ability  to  get  their  products  to  market  faster  than  their  competitors. 
Typically,  their  product  update  cycles  are  less  than  18  months.  Their  business  objectives 
are  centered  on  their  existing  and  potential  customer  base.  These  attributes  do  not  fit 
very  well  with  Navy  system  support  needs.  The  DoD  has  very  unique  applications  and 
very  low  volume.  Furthermore,  the  life  cycles  for  these  weapon  systems  are  lengthy, 
easily  exceeding  20-years,  and  because  of  the  policy,  procedures  and  guidance  provided 
by  DoD  5000,  the  Navy  requires,  and  can  only  expect,  minimum  technology  refresh  or 
updates  of  not  less  than  5  years.  [3)  McDermott]  The  challenge  for  the  DoD  and  the 
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Navy  is  to  provide  adequate  operational  readiness  and  maintainability  support  for  the 
entire  weapon  system  life  cycle. 

The  SSB  system  offers  a  support  infrastructure,  which  may  include  third  party 
support  to  bridge  the  gap  between  industry  business  objectives  and  the  Navy’s 
requirement  for  long-term  system  support.  The  Sunset  Supply  Base  concept  advocates 
building  partnerships  between  the  OEMs  and  third  party  technical  firms  (Sunset 
Suppliers)  via  contractual  relationships  where  appropriate.  These  Sunset  Suppliers, 
although  could  quite  possibly  be  the  OEM,  would  typically  be  a  small  build-to-print 
assembly  company  that  has  the  capability  to  manufacture  the  OEM’s  product.  Certain 
agreements  are  expected  on  both  sides(OEM  and  Sunset  Supplier)  that  provide  both 
benefit  and  security  to  their  respective  businesses.  The  OEM,  who  can  no  longer  justify 
the  business  case  to  make  certain  items  and  must  discontinue  the  product  as  a  business 
decision,  agrees  to  transfer  the  intellectual  property  and  assemblage  knowledge  for  a 
near-obsolete  product  to  the  Sunset  Supplier.  The  Sunset  Supplier  agrees  to  manage  this 
knowledge  respectfully  in  continuing  to  produce  these  products.  For  this  the  OEM  will 
receive  royalties  on  the  sale  of  all  products  produced  while  the  Sunset  Supplier  benefits 
by  gaining  exposure  and  sales  to  the  Navy.  Perhaps  the  cornerstone  to  this  arrangement 
is  the  Navy  internal  process  that  ensures  supportability  of  these  Sunset  products  by 
mitigating  any  component  part  obsolescence  issues  that  may  exist.  The  obsolescence 
reporting  is  accomplished  by  the  Navy  and  is  delivered  to  both  the  Program  Management 
Office  (PMO)  as  well  as  the  OEM.  Based  on  this  infonnation  the  PMO  can  now  decide 
the  most  appropriate  course  of  action  to  take  in  supporting  their  respective  programs. 
Figure  1,  The  COTS  Collaborative  Environment,  illustrates  the  SSB  process.  Presently, 
the  Navy  is  guided  through  DoD  5000  and  the  Performance  Based  Logistics  Initiative  on 
how  to  maximize  their  investments  for  supporting  present  and  developmental  systems 
long-term. 
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Assessment/Reporting/ 
Facilitating  Activity 


Appendix  C  Figure  1:  The  COTS  Collaborative  Environment 


The  Sunset  Supply  Base  system  uses  system  engineering  tools,  methods,  and 
processes  to  provide  proactive  activities  that  manage  the  obsolescence  risk  inherent  to 
COTS  use.  The  Sunset  Supply  Base  concept  is  not  intended  to  replace  traditional  support 
practices  but  rather  work  in  conjunction  with  them  to  yield  a  robust  infrastructure  that 
provides  the  PMO  with  cost  effective  solution  alternatives  in  the  face  of  obsolescence. 
The  net  result  is  greater  confidence  in  producing  the  lowest  Life  Cycle  Costs  (LLC)  while 
meeting  the  Navy’s  supportability  requirements.  The  key  to  the  SSB  implementation  is 
to  present  to  the  OEMs  an  alternative  business  case  that  is  favorable  to  their  business 
requirements.  The  flexibility  of  the  SSB  system  offers  an  opportunity  for  the  OEM  to 
gain  additional  revenue  for  nothing  more  than  sharing  the  intellectual  property  rights  to  a 
third  party  SSB  supplier  that  has  the  ability  to  manufacture  and  repair  the  OEM’s 
product.  In  effect  this  arrangement  accommodates  the  OEM  business  requirements. 


As  previously  described,  the  SSB  provides  a  mechanism  for  extending  product 
availability  beyond  the  OEM  assigned  date  to  discontinue  as  obsolete.  At  this  point  it  is 
important  to  understand  that  the  SSB  is  not  advocating  delivering  obsolete  technology  to 
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the  Navy’s  weapon  and  support  systems,  but  given  the  constraints  of  DoD  5000, 
Acquisition  Policies  and  Procedures,  and  the  fact  that  weapon  system  development,  at 
best,  exceeds  5  years,  the  SSB  system  infuses  stability  into  the  system  baseline 
configurations  over  a  defined  period  of  time.  These  periods,  time  scheduled  between 
technical  refresh  and  insertion,  can  be  between  5  and  1 5  years  depending  on  the  programs 
expectations.  Nevertheless,  the  SSB  concept  will  ensure  supportability  during  this  period 
by  establishing  an  arrangement  where  the  DoD/Navy  can  leverage  large  businesses  in 
their  strong  suit  of  technology,  market  leadership,  and  quantity  in  manufacturing,  while  at 
the  same  time  take  advantage  of  the  capabilities  of  the  small  businesses  in  terms  of  their 
agility,  small  production  run  capabilities,  and  their  desire  for  long-tenn  partnerships. 

Under  an  SSB  environment,  a  triple-win  situation  arises  for  all  parties.  The  Navy 
wins  by  getting  the  long-term  supportability,  maintainability,  and  operational  readiness  at 
reduced  life-cycle  costs.  With  this  the  PMO  can  in  effect  optimize  their  technology 
refresh  cycles,  upgrades  or  redesigns.  Furthermore,  they  also  can  expose  and  manage 
obsolescence  or  shortage  issues  associated  with  piece  parts  used  in  COTS  deployed 
throughout  all  participating  Navy  programs.  This  function  or  infonnation  and  risk 
sharing,  will  not  only  benefit  the  Sunset  Supplier  in  fulfilling  their  contractual  obligations 
but  will  serve  the  Navy  in  a  much  broader  sense  by  offering  the  derived  obsolescence  and 
shortage  data  to  the  Navy  as  a  whole.  In  managing  the  obsolescence  risk  in  this  fashion 
the  Navy  avoids  costly  redesigns  and  the  resulting  perturbations  to  the  logistic, 
maintenance,  and  other  support  functions. 

The  OEM  benefits  through  compensation  or  royalties  for  each  item  procured  by 
the  Navy.  In  addition,  they  get  to  claim  long-term  life-cycle  support  for  fielded  COTS  at 
lower  costs  and  minimal  impact  to  current  and  future  weapon  systems.  All  of  this  by 
simply  transferring  the  intellectual  property  rights  to  the  Sunset  Supplier.  Of  course,  the 
OEM  could  easily  decide  to  perform  the  role  of  the  Sunset  Supplier  themselves  if  they 
determine  that  the  benefits  derived  are  aligned  with  their  business  strategies. 

The  Sunset  Supplier  wins  in  terms  of  defining  a  new  market;  that  is,  new 
customers  and  new  product  lines.  They  also  receive  valuable  obsolescence  knowledge 
through  sustainment  engineering  expertise  from  the  SSB  infrastructure.  To  this  end,  they 


244 


are  able  to  develop  long-term  relationships  with  their  user  community  (OEMs  and  the 
Navy),  thereby  increasing  revenues,  establishing  security  for  their  business,  improving 
their  position  for  future  opportunities  and  gaining  the  ability  to  have  long-term  business 
planning. 
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III.  THE  BUSINESS  CASE 


This  document  serves  as  a  tool  that  supports  the  planning  and  decision-making 
with  respect  to  implementing  the  Sunset  Supply  Base  system.  Of  course,  it  could  not  be 
expected  that  the  SSB  system  would  be  the  solution  for  all  Navy  programs  nor  is  it 
intended  to  replace  traditional  support  practices,  but  as  mentioned  previously  its  true 
value  is  realized  when  its  implementation  is  in  conjunction  with  current  processes.  In 
fact,  the  acceptance  of  the  SSB  system  only  provides  the  PM  with  additional  cost 
effective  solution  scenarios  in  terms  of  weapon  system  support,  maintainability  and 
operational  readiness.  Therefore,  this  document  focuses  on  the  SSB  as  a  viable  solution 
alternative  for  the  Navy  PMOs  to  consider  in  their  decision-making  efforts  with  respect 
to  optimizing  return-on-investment  (ROI).  The  phrase  retum-on- investment  is  not 
necessarily  used  in  the  strict  sense  here,  but  rather  alludes  to  the  challenge  of  reducing 
life-cycle  costs  while  maintaining  adequate  support  levels  and  system  baseline  stability 
over  predefined  periods  of  time.  However,  since  ROI  is  in  effect  a  measure  of  a 
company’s  performance,  it  is  appropriate  in  this  case  since  the  task  of  the  PMOs  is  to  get 
the  “most  bang  for  the  buck”  so  to  speak,  which  is  in  essence  a  measure  of  their 
performance.  With  that  said,  the  analysis  presented  within  this  document  will  consider 
several  financial  metrics  to  be  discussed  in  more  detail  later  in  this  document.  For  now  it 
is  important  to  understand  the  value  of  this  business  case  in  the  selection  process  of 
solution  alternatives  within  a  solution  space.  This  business  case  analysis  will  detail  the 
likely  financial  results  and  business  consequences  of  implementing  the  SSB  system  so 
that  the  proposed  benefits  and  risks  are  succinctly  documented  and  understood. 

This  Business  Case  Analysis  (BCA)  looks  at  the  implementation  of  the  SSB 
system  on  the  Ship  Self-Defense  System  (SSDS)  Mkl.  It  will  consider  the  consequences 
of  implementing  the  SSB  infrastructure  for  providing  COTS  support  for  the  SSDS 
program.  These  consequences,  which  will  include  both  tangible  and  intangible  results, 
will  be  analyzed  for  conformance  to  DoD  policy,  program  requirements  and  overall 
cost/benefit.  Furthermore,  it  will  look  at  how  well  the  actual  implementation  relates  to 
the  goals  and  objectives  of  the  SSB.  In  short,  this  business  case  will  examine  the  likely 
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costs  and  benefits  that  will  result  in  implementing  the  SSB  system  for  supporting  the 
SSDS  program.  In  considering  SSB  implementation  this  analysis  will  report  on  four 
scenarios: 

•  Traditional  support  practices. 

•  Full  SSB  implementation  in  which  all  COTS  components  are  support  via 
Sunset  Supply  Base  infrastructure. 

•  Partial  SSB,  where  only  those  COTS  components  are  supported  in  which  the 
OEM  and  Sunset  Supplier  have  agreed  to  enter  into  a  contractual  relationship. 

•  Modified  SSB  implementation,  where  the  use  of  the  SSB  system  is  only  used 
where  it  makes  sense.  The  SSDS  Cots  Working  Group,  which  is  responsible 
for  overall  execution  and  management  of  the  SSB  system  for  a  particular 
program,  makes  these  decisions. 
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IV.  SUNSET  SUPPLY  BASE  GOALS  AND  OBJECTIVES 


In  establishing  specific  goals  and  objectives,  it  is  important  to  understand  the 
DoD/Navy  needs  and  expectations.  In  general,  the  DoD/Navy  is  focused  on  improving 
program  supportability  and  extending  the  reparability  of  COTS  for  5  years  and  beyond. 
Furthermore,  they  are  looking  for  a  mechanism  that  will  align  COTS  update  cycles  with 
program  technology  refresh  and  insertion  cycles.  The  SSB  accomplishes  this  by 
providing  valuable  insight  to  potential  obsolescence  issues  through  available  predictive 
toolsets.  Additionally,  the  SSB  will  mitigate  maintenance  and  supportability  issues  at  the 
assembly  level.  Having  this  capability  is  only  part  of  the  solution  though;  success  will 
depend  on  productive  and  effective  partnering  between  government  and  private  sector 
entities.  Moreover,  this  partnering  must  be  met  with  a  willingness  to  develop  long-term 
relationships.  Therefore,  one  of  the  objectives  of  the  DoD/Navy  within  the  SSB 
environment  is  to  encourage  such  teaming  while  ensuring  desirable  benefits  for  ah 
participants  while  protecting  individual  interests  (i.e.  COTS  OEMs’  proprietary  design 
rights).  In  developing  these  long-term  relationships,  the  DoD/Navy  must  precisely 
identify  the  roles  and  responsibilities  of  ah  participants  in  the  SSB  process.  A  first  step  is 
to  define  the  interfaces  and  establish  how  these  interfaces  will  be  managed  to  achieve 
efficiency  and  success.  Continued  success  will  depend  on  constant  awareness  and 
assessment  as  to  why  each  entity  chooses  to  participate  and  to  provide  incentives  for 
continued  involvement. 

As  described,  the  main  objective  of  the  SSB  is  to  provide  an  alternative  solution 
to  the  PMs  for  supporting  COTS  products  over  a  predefined  period  of  time  at  an 
affordable  and  even  reduced  cost  to  the  program.  There  are  also  specific  goals  of 
implementing  the  SSB.  These  goals  are  listed  below.  In  reviewing  this  list,  keep  in  mind 
that  the  overarching  objective  is  to  be  able  to  reach  these  goals  while  reducing  Life  Cycle 
Costs  (LCC).  In  each  case,  achieving  the  respective  goal  becomes  a  valuable  asset  in 
itself  and  the  investment  needed  to  reach  each  goal  must  be  appropriate  for  the  value 
derived. 
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A.  SSB  SPECIFIC  GOALS: 

Achieve  significant  and  quantifiable  cost  savings  over  the  product  life  cycle. 

The  SSB  process  makes  upfront  cost  assessments  that  will  provide  valuable 
knowledge  needed  for  effective  decision-making.  Cost  structures  will  be  tracked  and 
continually  assessed  over  the  product  life  cycle  resulting  in  the  capability  of  procuring 
products  at  the  point  of  customer  demand  vice  Life  of  Type  Buys  (LTB)  at  the  assembly 
level  based  on  traditional  predictive  models. 

To  be  able  to  identify,  quantify,  and  mitigate  supportability  risk  to  programs. 

The  SSB  process  must  methodically  and  adequately  derive  the  risks  associated 
with  obsolescence.  These  risks  identified  must  be  measurable  in  order  to  successfully 
mitigate  them.  Furthermore,  the  information  and  knowledge  gained  through  this  process 
must  be  accessible  by  all  participants. 

Extend  the  life  cycle  and  supportability  of  COTS. 

In  defining  the  metrics  for  ensuring  long-tenn  COTS  supportability,  the  SSB 
process  must  consider  the  war-fighter  supportability  requirements.  The  challenge  is  to 
meet  expected  military  performance  goals  by  continuing  to  leverage  commercial 
technology  developments  while  at  the  same  time  being  able  to  offset  the  problem  of 
diminishing  material. 

Provide  infrastructure  to  support  existing  platform/combat  systems  in  support  of  the 
PMO. 

The  SSB  must  focus  on  the  PMO  objectives  for  developing  and  sustaining 

weapon  systems.  To  this  end,  the  SSB  must  be  capable  of  effectively  identifying 

program  risk  and  then  mitigate  these  risks  as  they  relate  to  COTS  and  life  cycle 

management.  Success  will  hinge  on  providing  an  infrastructure  as  early  as  possible  in  the 

development  process  in  order  to  establish  the  supportability  of  COTS  components. 

A  reliable,  affordable,  repeatable,  and  expandable  process  that  meets  the  customer’s 
performance  expectations  (e.g.,  accessible,  transportable,  maintainable,  predictable). 

The  SSB  process  must  be  flexible.  To  this  end,  the  characteristics  of  such  a 
process  must  be  definable  and  repeatable.  In  effect,  the  SSB  process  must  provide  an 
additional  option  to  supporting  fielded  COTS  hardware  as  well  as  an  alternative  solution 
to  DMSMS/Obsolescence  Management  for  the  overall  program.  This  utility  must  have 
minimal  to  no  impact  on  system  perfonnance. 
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Institutionalize  methods  for  proactive  management  of  COTS  including  DMSMS  issues. 

The  institutionalization  of  these  methods  will  require  the  development  of  non¬ 
standard  Integrated  Logistic  Support  (ILS),  contract  strategies  and  implementation 
methodologies  that  will  access  the  commercial  support  base.  In  doing  this,  the  process 
must  be  sensitive  to  proprietary  design  rights  and  provide  a  forum  for  appropriate 
negotiations.  The  methods  employed  shall  improve  product  supportability  problem 
detection  and  provide  sufficient  time  for  appropriate  decision-making  processes  to 
implement  the  recommendations  of  the  analysis  for  alternatives  and  solutions.  Overall  it 
shall  provide  aid  to  the  decision-maker  by  producing  technology  assessment  and 
management  guidance  at  various  levels  -  piece  parts,  lowest  replaceable  units,  units, 
subsystems  and  multiple  platforms. 

A  system  that  leverages  Navy  and  commercial  supportability  assets  and  provides  a 
networked  solution. 

The  key  to  achieving  this  goal  is  for  the  SSB  process  to  effectively  coordinate  the 
existing  governmental  functions  that  currently  perfonn  DMSMS/Obsolescence 
Management.  By  taking  advantage  of  the  various  agencies  that  provide  such  functions, 
the  SSB  process  leverages  this  information  or  knowledge  on  behalf  of  the  PMO  as  well 
as  participating  commercial  supportability  assets.  Success  will  depend  on  a  robust  and 
effective  communication  scheme  that  is  both  maintainable  and  fully  meshed  across  the 
SSB  entities. 

Leverage  across  government  programs  with  extended  applicability  through  contract 
strategies,  methodologies,  and  incentives  to  entice  commercial  industry  participation. 

The  process  must  be  transportable  in  terms  of  its  applicability  to  various  DoD 
entities  and  their  contract  strategies.  The  SSB  process  will  attempt  to  identify  and 
integrate  common  functions  across  DoD/Navy  agencies  that  deal  with  integrated 
logistical  support.  To  this  end,  a  more  focused  effort  towards  COTS  supportability  is 
realized  that  should  also  provide  greater  flexibility  in  dealing  with  the  commercial  sector. 
This  scenario  should  be  capable  of  providing  incentives  for  the  commercial  industry  into 
develop  long-term  relationships  with  the  DoD/Navy. 

Forecast  budget  requirements  in  support  of  the  programs/war  fighter/consumer. 

Key  to  meeting  this  goal  is  the  level  of  confidence  achieved  in  presenting  the 
outputs  from  obsolescence  assessments  and  supportability  method  trade-offs.  This 
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confidence  should  be  realized  at  the  PMO  level  and  provide  them  with  predictive 
information  that  will  empower  them  to  make  the  most  appropriate  programmatic 
decisions. 

Improve  schedule  flexibility  and  support  options  of  system  upgrades  or  new  development 
initiatives. 

Schedule  flexibility  refers  to  optimizing  the  provisioning  timeframes. 
Optimization  will  be  accomplished  by  providing  alternative  support  options  for  system 
upgrades  or  new  development  efforts.  These  alternatives  should  be  tailored  for  the 
warfighter  and  the  support  activities’  needs.  The  benefits  that  the  SSB  will  strive  for  are 
immediate  supportability,  elimination  of  government  levels  of  inventory  stock, 
expeditious  and  reliable  delivery  to  the  warfighter,  and  commercial  warranty  of 
components. 
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V.  SUNSET  SUPPLY  BASE  OBJECTIVES 


The  objectives  of  the  SSB  process  provide  the  rational  for  deciding  the 
applicability  of  the  SSB  infrastructure.  By  formally  stating  the  overall  objectives  of  this 
subject,  we  essentially  establish  a  basis  by  which  the  analysis  can  assign  values  to 
specific  benefits  and  ultimately  guide  this  effort  into  making  a  reasonable  conclusion 
statement  and  provide  realistic  recommendations.  These  objectives  are  categorized  and 
discussed  below. 

B.  FINANCIAL  AND  BUSINESS  PERFORMANCE 

The  overall  objective  mandated  by  the  current  Department  of  Defense  (DoD) 
Systems  Acquisition  Process  (DoD  5000)  is  to  improve  performance,  including  quality, 
at  lower  costs.  This  process  focuses  on  delivering  advanced  or  at  least  current 
technology  to  the  warfighter  faster.  Program  Management  Offices  (PMO)  are  challenged 
to  offer  rapid  acquisition  of  reliable  and  supportable  technology  while  also  reducing  Total 
Ownership  Costs  and  improved  affordability.  In  meeting  this  challenge,  we  see  a 
proliferation  of  interoperable  systems  using  COTS  products.  Also,  we  see  quite  often  the 
use  of  similar  COTS  across  weapon  systems  that  are  separate  and  distinct  and  have  no 
physical  or  logical  dependence  on  each  other.  The  use  of  COTS  in  itself  brings  a  certain 
risk  with  regards  to  the  ability  to  support  them  long-tenn  due  to  Diminishing 
Manufacturing  Sources,  and  Material  Shortages  (DMSMS)  and  obsolescence,  and  the 
fact  that  many  different  programs  or  weapon  systems  are  using  the  same  COTS  products, 
only  increases  the  risks  and  threats  to  system  sustainability  across  these  programs. 
Therefore,  the  SSB  process  attacks  these  two  areas,  risk  and  costs,  by  providing  a 
potential  architectural  solution  that  specifically  addresses  the  issue  of  obsolescence  and 
DMSMS,  thereby  reducing  both  risk  and  costs  to  the  program.  In  answering  the  mail  on 
this,  so  to  speak,  the  SSB  process  strives  to  compress  the  provisioning  timeframes,  by 
partnering  with  private  industry  and  providing  them  with  incentives  (as  previously 
mentioned)  to  assume  some  of  the  risk  (i.e.  immediate  supportability  and  warranty)  and 
costs  (i.e.  stockage,  storage  and  issue  of  COTS  spares  and  repair  parts).  Establishing 
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these  characteristics  will  have  positive  impacts  in  terms  of  supportability,  program 
planning,  program  risk  and  TOC. 

C.  STRATEGIC  POSITION  AND  OWNERSHIP 

Partnering  with  the  private  sector  to  take  advantage  of  commercial  technology 
advances  as  well  as  support  and  maintenance  are  firmly  established  mechanisms  used  by 
the  DoD/Navy.  The  potential  cost  savings  that  the  DoD  detennined  would  be  possible  by 
pooling  the  expertise  and  capabilities  found  in  private  industry  brought  about  this 
situation.  Partnering  takes  on  many  forms  (i.e.  teaming,  procurement/sales,  work-share 
arrangements);  but  the  important  point  here  is  that  they  exist  and  are  being  utilized  more 
and  more  by  the  PMOs.[5)  OSD]  Furthermore,  the  Program  Manager  (PM)  as  part  of  the 
acquisition  strategy  must  establish  a  support  strategy  (PM  Toolkit).  In  fact,  this  plan 
must  “address  life-cycle  sustainment  and  continuous  improvement  of  product 
affordability,  ...  and  supportability,  while  sustaining  readiness.”  [6)  OSD]  To  this  end, 
the  PM  has  at  their  disposal  a  set  of  tools  used  to  help  in  the  decision-making  process  for 
determining  the  most  cost  effective  alternative  for  supporting  the  system.  The  SSB 
architecture  is  challenged  to  position  itself  within  this  toolset  as  a  viable  alternative.  A 
strategy  for  positioning  the  SSB  architecture  within  the  supportability  analysis  repertoire 
would  include  establishment  or  improvement  of  strategic  alliances.  The  SSB  architecture 
has  already  been  implemented  on  three  Navy  programs  (Ship  Self  Defense  System 
(SSDS)  MKI,  SSDS  MKII,  and  Sonar  Mine  Detecting  Set  (AN/ASQ-20X))  The 
relationships  developed  between  the  participating  commercial  entities  and  the  Navy 
agencies  should  lobby  the  DoD  executive  offices  with  sufficient  detail  as  to  the  benefits 
of  implementing  the  SSB  architecture  on  the  respective  programs.  Since  the  SSB 
architecture  was  built  on  existing  expertise  and  functions  within  the  Navy,  the  SSB 
process  is  in  fact  owned  and  therefore  managed  by  the  DoD/Navy.  Additionally,  the 
long-term  relationships  that  will  be  realized  through  the  SSB  environment  should  further 
emphasis  and  influence  the  policy-making  office  within  the  DoD  as  to  the  potential  gains 
not  only  in  the  perfonnance  of  supportability  and  sustainability  functions,  but  in 
maintaining  key  core  government  technologies  as  well. 
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D.  OPERATIONS  AND  FUNCTIONS 


The  objective  here  is  simple  -  to  improve  program  supportability  by  extending 
COTS  reparability  for  5  years  and  beyond.  Why  5  years?  Typically,  the  development  of 
military  systems  has  been  10  to  15  years,  and  the  DoD/Navy  have  experienced 
approximately  5  to  7  year  efforts  for  technology  refresh  or  insertion.  The  reason  for  this 
is  primarily  due  to  the  inherent  nature  of  DoD  to  take  a  purposely  conservative  and 
thoughtful  approach  to  implementing  change.  The  DoD  have  constructed  very  well- 
defined  controls  for  managing  the  acquisition  process,  which  have  in  effect  created 
obstacles  for  keeping  pace  with  commercial  product  development.  This  conservative 
approach  has  resulted  in  a  disconnect  between  the  life  cycle  of  COTS  products  and  the 
typical  reaction  time  of  the  DoD/Navy  to  field  new  equipment.  The  life  cycle  for  COTS 
products  are  approximately  18  months  to  as  much  as  5  years  (although  rare),  whereas  the 
DoD  typically  takes  2  to  3  years  in  planning  and  an  additional  5  to  7  years  for 
implementation.  The  problem  of  supporting  these  weapon  systems  is  further 
compounded  when  these  weapon  systems  are  expected  to  perform  over  an  extended  life 
cycle  -  possibly  greater  than  15  years.  Given  this  situation,  the  SSB  process  has 
identified  as  an  objective  to  support  the  product  development  cycle  and  ultimately  the 
system  life  cycle.  For  weapon  systems  that  have  deployed  COTS,  the  SSB  architecture 
offers  an  opportunity  for  supporting  existing  technologies.  Success  in  these  areas  will 
fulfill  the  SSB  architecture’s  commitment  to  improving  operations  and  functions  within 
the  PMO  since  they  are  the  ones  who  must  manage  the  program  over  its  lifetime. 

E.  PRODUCT  AND  SERVICES 

In  terms  of  product  and  service,  the  SSB  architecture  offers  a  truly  unique  and 
effective  process  for  improving  customer  satisfaction.  The  customer  in  this  case  is  the 
warfighter  who  use  and  maintain  the  system.  The  PMO  must  ensure  that  they  deliver  key 
enabling  technologies  that  must  also  be  supportable  for  fixed  periods  of  time.  The  SSB 
architecture  offers  an  additional  alternative  for  the  PMO  to  consider  as  part  of  their 
support  strategy.  Furthermore,  the  SSB  process  allows  the  PM  to  match  the  COTS 
update  cycles  with  the  program’s  technical  roadmap  or  refresh  effort.  The  product  is 
essentially  a  set  of  well-defined  tools  that  provide  obsolescence  indicators  and  reports  as 
well  as  the  ability  to  mitigate  maintenance  and  supportability  issues  at  the  assembly  level. 
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By  establishing  and  managing  this  information,  the  PMO  becomes  empowered  with  the 
knowledge  necessary  to  deliver  an  improved  customer  service.  In  the  long  run  the 
system  integrity  is  maintained,  which  has  several  implications  in  terms  of  Integrated 
Logistical  Support  (ILS)  -  i.e.  training,  manuals,  configuration  control. . . 

F.  IMAGE 

This  is  an  unusual  area  since  we  are  not  talking  about  the  image  of  a  specific 
entity  like  an  agency  or  company.  The  objective  here  is  to  promote  the  idea  of  the  SSB 
architecture  as  a  viable,  effective  and  valuable  alternative  based  on  costs  and  benefits.  At 
first  glance,  it  may  appear  to  some  that  the  SSB  process  is  trying  to  hold  onto  older 
technology.  Old,  meaning  technology  associated  with  COTS  products  that  have  been 
discontinued.  The  fact  of  the  matter  is  that  the  DoD/Navy  has  not  been  able  to  keep  up 
with  commercial  product  update  cycles  as  earlier  mentioned.  In  a  perfect  world,  it  would 
be  great  to  be  able  to  transfer  commercial  state-of-the-art  technology  to  the  warfighter  the 
moment  it  was  deemed  ready  or  at  least  when  it  hit  the  market.  But  as  described 
previously,  the  acquisition  process  institutionalized  by  the  DoD  offers  too  many  obstacles 
to  achieve  this.  Although  Acquisition  Reform  has  yielded  great  gains  in  streamlining  the 
acquisition  process,  it  is  still  purposely  conservative,  deliberate  and  methodical,  which 
translates  to  slow  when  compared  to  the  current  commercial  development  cycles.  So  as 
the  military  acquisition  community  is  pushed  by  DoD  5000  to  use  COTS  products  as  the 
preferred  alternative  for  use  in  its  weapon  systems,  the  obsolescence  issues  are  slowly 
getting  worse.  Also,  extending  the  service  life  of  currently  fielded  systems  has  been  the 
norm  for  many  years.  The  B-52  platform  is  probably  the  most  notable  and  perhaps  worst 
case.  It’s  been  in  service  since  1955,  and  is  not  expected  to  be  phased-out  until  2040 
(94+  years).  The  1994  issue  of  Army  RD&A  Bulletin  highlighted  this  fact  by  stating  how 
many  current  military  systems  are  generally  on  a  54-year  replacement  cycle  while 
technology  “...has  a  half-life  from  2  to  10  years”.  [7)  Augustine]  Most  systems  don’t 
have  such  a  life  expectancy,  but  15  to  30  years  is  fairly  common.  And  when  you  realize 
that  the  fast  pace  nature  of  the  OEM  often  take  their  products  off  the  market  regardless  of 
the  impact  to  the  Navy,  its  not  hard  to  understand  the  need  for  a  process  that  is  designed 
to  provide  real  solutions  to  this  obsolescence  issue.  This  is  not  news  to  the  PMOs  as  they 
have  been  force  to  deal  with  DMSMS,  which  is  why  they  routinely  fund  and  support 
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DMSMS  activities  to  meet  the  Navy’s  ever  increasing  need.  The  SSB  system  is  designed 
to  specifically  address  these  risks,  but  more  importantly,  it  is  expected  to  work  with 
existing  support  systems  as  an  interfacing  method  to  optimize  solutions  in  managing  the 
obsolescence  risk  on  COTS  products.  Furthermore,  not  only  does  the  SSB  system  offer 
significant  supportability  and  cost  benefits  to  the  PMOs,  it  also  strives  to  be  recognized 
as  a  contributor  in  Navy/Industry  cooperation,  a  major  initiative  underway  particularly  in 
the  Navy.  Getting  this  point  across  is  one  of  the  objectives  of  this  business  case. 
Therefore  a  case  will  be  made  based  on  both  tangible  and  intangible  benefits  and  the 
costs  to  achieve  them,  hopefully  leading  to  a  department  wide  adoption  of  the  SSB 
concept.  So  promoting  the  image  of  the  SSB  is  a  challenging  yet  important  objective  for 
this  business  case. 
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VI.  BUSINESS  NEEDS 


A.  BACKGROUND 

Over  the  years  the  Department  of  Defense  (DoD)  has  been  plagued  with 
development  programs  that  have  experienced  significant  cost  overruns  and  schedules  that 
have  slid  to  the  right  all  too  often.  In  the  end,  the  delivered  weapon  systems  prove  to  be 
of  little  value  due  to  the  enormous  delay  of  deploying  them.  The  challenge  to  design, 
develop  and  implement  processes  to  address  these  issues  is  an  ongoing  initiative.  Making 
government  more  efficient  has  been  a  continuous  theme  for  years  now.  In  fact,  as  early 
as  1980  Congress  passed  the  Paperwork  Reduction  Act  in  a  step  towards  improving 
government  performance.  In  1993  the  Government  Performance  and  Results  Act,  which 
required  government  agencies  to  set  strategic  goals,  measure  performance,  and  reported 
on  the  degree  to  which  goals  were  met. [8)  GAO]  More  recently,  in  1996,  Congress 
passed  the  Information  Technology  Management  and  Reform  Act  (Clinger-Cohen  Act). 
This  act  essentially  required  government  agencies  to  improve  the  way  they  selected  and 
managed  Infonnation  Technology  (IT)  projects. [9)  Clinger-Cohen]  Soon  after,  the  Office 
of  Management  and  Budget  (OMB)  established  circular  A-130,  Management  of  Federal 
Information  Resources.  The  purpose  of  this  circular  was  to  further  establish  a  policy  for 
managing  Federal  Information  Resources.  [10)  OMB]  The  result  of  the  Clinger-Cohen 
Act  and  OMB  Circular  A-130  was  the  establishment  of  a  comprehensive  approach  by 
individual  federal  agencies  to  improve  the  acquisition  and  management  of  their  IT 
development  efforts.  Working  within  this  new  process,  PMOs  began  aligning  their 
resources  in  support  of  their  respective  strategic  missions.  To  be  effective  they  began  to 
implement  investment  management  strategies  that  established  control  mechanisms  that 
would  align  the  appropriation  of  funds  to  their  strategic  mission.  In  effect,  they  improved 
the  way  they  selected,  planned  and  managed  their  development  programs  by  restructuring 
the  way  they  allocated  their  resources  before  any  initial  investment  was  made  in  a 
particular  program.  One  of  the  ways  these  agencies  achieved  this  was  rethinking  the 
selection  process.  Traditionally,  priorities  were  given  to  their  programs  and  subsequent 
decisions  on  which  programs  would  be  funded  were  made  based  on  this.  Under  this  new 
way  of  thinking,  the  selection  process  was  centered  on  a  program’s  cost,  benefit  and  risk 
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assessments.  These  three  elements  would  be  quantified  and  analyzed  prior  to  any  release 
of  funds.  In  essence,  a  Business  Case  Analysis  was  performed  as  part  of  the  selection 
process. 

In  terms  of  the  Sunset  Supply  Base  concept,  a  Business  Case  Analysis  (BCA)  is 
presented  in  this  document  to  reflect  its  benefits  and  importance  to  the  DoD/Navy’s 
mission.  Therefore,  this  document  includes  information  on  scope,  alternatives,  costs, 
benefits,  risk  and  acquisition  strategy.  An  overview  of  the  SSB  process  has  already  been 
given,  as  well  as  its  goals  and  objectives.  As  part  of  this  analysis  we  must  align  these 
with  the  DoD/Navy  objectives  for  product  support.  At  this  point  it  is  important  to 
address  these  DoD/Navy  objectives  in  broad  terms  as  identified  below. 

B.  BUSINESS  CASE 

In  today’s  environment,  PMs  are  guided  to  make  program  technical  decisions 
based  on  the  business  objectives  of  their  agency.  In  terms  of  product  support  solutions, 
system  baseline  assessments  are  made,  which  form  the  basis  for  conducting  the  business 
case  analysis.  The  Deputy  Under  Secretary  of  Defense  (Logistics)  describes  the  business 
case  as  “...a  tool  used  to  manage  business  process  improvement  activities  from  inception 
through  implementation.  A  business  case  is  a  document  that  identifies  functional 
alternatives  and  presents  economical  and  technical  arguments  for  carrying  out 
alternatives  over  the  life  cycle  to  achieve  stated  business  objectives  or  imperatives."  [11) 
DUSDL]  Business  Cases  are  created  all  the  time  for  Perfonnance  Based  Logistics  (PBL) 
tasking.  PBL  is  a  NAVICP  initiative  that  focuses  on  improving  supportability  as  well  as 
cost  of  ownership  reduction  efforts.  We  will  cover  PBL  in  more  detail  later  on  in  this 
document,  but  for  now  it  is  important  to  understand  that  a  Business  Case  Analysis  is 
conducted  for  PBL  in  which  alternative  support  solutions  are  assessed  in  terms  of  their 
ability  to  meet  the  logistics  performance  objectives  of  the  warfighter.  To  this  end,  there 
are  guidelines  under  DoD  5000  [12)  DoD]  for  cost/benefit  analysis  used  specifically  for 
making  business  trade-offs  decisions  with  regards  to  the  most  cost  effective  product 
support  solution(s).  So  to  recap,  the  Navy  looks  to  the  Business  Case  for  making 
decisions  on  support  strategies  in  an  effort  to  provide  the  best  supportability  scenario  at 
the  most  affordable  level. 
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C.  PRODUCT  SUPPORT 

Product  support  is  a  package  of  logistical  support  functions  necessary  to  maintain 
the  readiness  and  operational  capability  of  a  system.  To  achieve  the  appropriate  level  of 
readiness  and  operational  capability  of  a  system,  a  system  must  be  designed  to  be 
reliable,  maintainable,  interoperable,  and  provide  internal  diagnostics  and  prognostics. 
But  just  as  important  is  the  logistical  support  functions  which  include  supply  chain 
integration,  sustainment  engineering,  obsolescence  management,  distributed  training,  and 
a  manageable  integrated  weapon  system  data  environment.  These  functions  all  play  an 
important  role  in  supporting  military  capability.  Military  capability  is  defined  by  four 
major  components:  [13)  DAU] 

Force  Structure  -  Refers  to  the  capability  of  a  military  force  based  on  its  structure. 
A  force  structure  must  be  robust,  capable,  equipped,  trained,  organized,  and  optimized  in 
order  to  succeed  on  the  battlefield.  Product  support  is  a  crucial  element  to  meeting  the 
required  level  of  capability. 

Modernization  -  Refers  to  the  task  of  a  military  force  to  modernize  its  forces  and 
the  weapon  systems  that  they  deploy.  It  is  a  key  element  to  military  superiority  over 
present  and  future  adversaries. 

Readiness  -  Refers  to  the  capability  of  a  military  force  to  accomplish  the  expected 
mission  for  which  they  were  designed.  Although  military  readiness  is  difficult  to 
adequately  quantify  as  a  whole,  the  support  component  is  not.  Without  proper  support, 
weapon  system  sustainment  and  ultimately  warfighter  capability  are  severely 
compromised. 

Sustainability  -  Refers  to  the  capability  of  a  military  force  to  maintain  the 
necessary  level  and  duration  of  operations  to  achieve  military  objectives.  Sustainability 
depends  on  ready  forces,  materiel,  and  consumables  in  enough  quantities  and  working 
order  to  support  military  efforts. 

With  respect  to  each  of  these  four  components,  product  support  plays  a  crucial 
role.  In  terms  of  force  structure,  by  increasing  system  availability  levels  through 
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improved  product  support  mechanisms  we  can  also  minimize  the  support  requirements 
for  military  manpower.  Reducing  manpower  requirements  in  the  support  area  translates 
to  a  reallocation  of  these  resources  to  core  warfighting  missions.  With  respect  to 
modernization,  support  strategies  that  result  in  lower  support  costs  means  that  these  funds 
can  be  redirected  to  achieve  the  Navy’s  re-capitalization  and  modernization  objectives. 
Readiness  is  improved  when  support  strategies  are  designed  and  executed  to  meet 
military  performance  requirements.  And  finally,  if  the  support  strategy  are  designed  and 
executed  to  accurately  assess  support  requirements,  then  the  weapon  systems  themselves 
become  more  sustainable.  To  optimize  readiness  and  sustainability,  a  product  support 
process  must  be  capable  of  anticipating  vulnerabilities  in  the  supply  chain  and  provide 
resources  at  the  moment  they  are  needed.  In  fact,  per  NAVAIR’s  Contracting  for 
Supportability  Guide,  PMs  are  directed  to  a  strategy  that  procures  these  items  when  they 
are  required.  [14)  NAVAIR] 

In  the  end,  the  Navy’s  objective  for  product  support  in  a  rather  broad  sense  is  to 
migrate  to  a  product  support  strategy  that  is  based  on  output  measures  such  as  availability 
of  weapon  system  equipment.  In  fact,  the  Office  of  the  Deputy  Under  Secretary  of 
Defense  for  logistics  and  Material  Readiness  had  chaired  a  joint  service/defense  agency 
team  in  preparing  a  comprehensive  product  support  strategy,  titled  Product  Support  for 
the  21st  Century,  which  advocates  a  more  customer-focused  product  support  environment. 
[15)  DUSD]  An  environment  that  offers  a  “best  value”  approach  to  fulfilling  warfighter 
demands. 

D.  LIFE-CYCLE  MANAGEMENT 

One  of  the  main  objectives  of  our  military  today  is  to  continuously  improve  the 
operational  effectiveness  of  its  weapon  systems  resulting  in  a  more  capable  warfighter. 
To  this  end,  life-cycle  support  plays  a  critical  role  in  ensuring  that  the  warfighter’s 
requirements  are  met  throughout  the  life  cycle  of  the  weapon  system.  Since  many  of  the 
Navy’s  weapon  systems  can  expect  life  cycles  that  exceed  10  and  even  20  years,  the  DoD 
as  part  of  their  Joint  Vision  2010  and  2020  have  identified  logistics  as  a  crucial  element 
for  warfighter  operational  effectiveness.  The  weapon  system  support  infrastructure  must 
be  capable  of  providing  immediate  support  in  a  crisis  situation.  These  product  support 
strategies  must  be  tailored  in  order  to  provide  appropriate  levels  of  readiness  and 
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sustainment  to  all  elements  of  the  strategic  and  tactical  operational  forces.  [16)  DoD]  By 
promoting  a  tailored  product  support  environment,  the  warfighter  will  benefit  in  tenns  of 
responsiveness.  A  more  tailored  approach  translates  to  more  flexibility  and  ultimately 
greater  effectiveness  in  life-cycle  support.  Needless  to  say,  the  acquisition  community  is 
constrained  by  very  institutionalized  policies  and  procedures;  nevertheless,  there  are  still 
opportunities  for  innovative  and  collaborative  strategies  that  infuse  flexibility  into  the 
support  process.  Joint  Vision  2010  and  2020  places  more  focus  on  logistics  and 
challenge  the  acquisition  community  to  expose  these  opportunities  in  meeting  the 
demands  of  the  warfighter.  [17)  DoD]  This  challenge  is  continuous  and  is  focused  on 
meeting  the  needs  of  evolving  warfighter  requirements.  So  to  effectively  meet  the 
product  support  demands  over  the  life  cycle  of  the  weapon  system  the  PMO  must  also 
manage  the  warfighter’s  requirements  as  well.  Part  of  this  responsibility  includes 
identification  and  insertion  of  technology.  A  planned  approach  for  technology  insertion 
must  match  warfighter  requirements.  Based  on  these  requirements  and  the  available 
technology,  the  Program  Manager  (PM)  must  decide  on  an  appropriate  technology 
refresh  cycle.  These  tech  refresh  cycles  should  be  determined  around  technology, 
warfighter  requirements,  and  potential  enhancements.  They  should  not  be  based  on 
material  shortages  or  obsolescence.  With  that  said,  the  PM  should  have  at  their  disposal 
a  set  of  product  support  alternatives  to  optimize  this  effort  over  the  life  cycle  of  the 
weapon  system. 

1.  Cost 

Per  DoD  5000.1,  Departments  are  expected  to  integrate  the  acquisition  and 
logistics  processes  that  are  focused  on  Total  Ownership  Costs  (TOC). [12)  DoD] 
Furthermore,  the  directive  identifies  supportability  as  a  key  performance  factor.  In  effect, 
the  support  strategy  becomes  a  part  of  the  Systems  Engineering  process.  In  this  way,  the 
PM  can  gain  better  control  of  the  costs  associated  with  supporting  the  weapon  system. 
Cost  has  become  an  even  greater  concern  in  the  DoD’s  current  fiscal  environment.  The 
military  is  challenged  to  continue  an  aggressive  modernization  program  in  light  of 
increased  operations.  Additionally,  modernization  efforts  are  further  threatened  due  to 
expectations  of  near-term  readiness  levels  of  existing  systems  and  reductions  in 
infrastructure.  The  days  of  simply  increasing  the  defense  budget  are  gone.  Given  the 


263 


tempo  of  military  operations  over  the  years,  it  is  easy  to  conclude  that  these  operations 
take  precedence  over  future  modernization  efforts.  In  fact,  according  to  the  Joint 
Aviation  Logistics  Board  (JALB)  June  1999  report  on  Commercial  Support  of  Aviation 
Systems,  since  1990  procurement  activities  have  dropped  by  53  percent  where  operations 
and  maintenance  efforts  have  decreased  by  only  15  percent.  [18)  Mcllvaine]  From  this  it 
is  easy  to  see  that  replacement  of  existing  systems  are  being  delayed  as  well  as  a  likely 
lengthening  in  the  technology  refresh  cycles.  In  the  May  1997  Report  of  the  Quadrennial 
Defense  Review,  then  Secretary  of  Defense  William  Cohen  highlighted  this  fact  by 
stating  that  we  are  facing  a  gradual  aging  of  military  force.  [19)  DoD]  As  a  result  of  this 
environment,  current  political  pressures  have  driven  the  PMOs  to  explore  more 
economical  alternatives  to  supporting  warfighter  requirements. 

2.  DoD  Supportability  Goals 

As  stated  earlier,  the  Department  of  Defense  Directive  5000  series  directs  the 
PMOs  to  focus  on  TOC  as  a  key  element  of  measure  for  acquisition  performance  while 
meeting  warfighter  requirements.  The  challenge  is  to  meet  warfighter  demands,  in  terms 
of  overall  capability,  at  an  affordable  cost.  Since  there  is  an  obvious  cost  delta  from  one 
support  method  to  the  next,  we  conclude  that  the  support  strategy  directly  impacts  both 
warfighter  capability  and  cost.  Therefore,  DoDD  5000.1  defines  supportability  as  a  key 
performance  variable  in  the  systems  engineering  process  and  it  further  emphasizes  the 
importance  of  supportability  in  light  of  a  continual  evolving  logistics  state  that  is  striving 
to  support  joint  operational  forces.  In  an  effort  to  gain  control  over  the  impacts  that 
supportability  has  on  cost  and  warfighter  capability,  DoDD  5000  instructs  the  PMs  to 
consider  logistics  as  part  of  the  design  process  leading  to  a  support  strategy  that  is  applied 
throughout  the  weapon  system  life-cycle.  The  ultimate  objective  being  the  delivery  of 
reliable  weapon  systems  that  can  be  cost-effectively  supported.  This  demand  for  full- 
life-cycle  support  management  pushes  the  PMs  to  plan  for  initial  procurement,  re¬ 
procurement,  and  post-production  support.  In  planning  to  support  existing  as  well  as 
weapon  systems  under  development,  the  following  goals  have  been  derived  from  the 
DoDD  5000  guidelines.  [20)  DoD] 
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1)  Integrate  supply  chains  to  achieve  cross-functional  efficiencies  and  provide 
improved  customer  service  through  performance-based  arrangements  or 
contracts. 

The  PM  should  take  advantage  of  the  existing  functions  that  exist  within  the  DoD 
as  well  as  the  contractor  base.  Consideration  given  to  these  entities  should  lead  to  an 
integration  of  these  elements  through  traditional  contracting  arrangements.  In  this  way 
the  PM  can  optimize  the  support  process.  By  integrating  the  expertise  from  these  cross¬ 
functional  elements  the  PM  can  expect  greater  performance  and  improve  customer 
service. 

2)  Segment  support  by  system  or  subsystem  and  delineate  agreements  to  meet 
specific  customer  needs. 

In  terms  of  meeting  warfighter  support  requirements  the  PM  should  consider 
applying  support  methods  specific  to  the  needs  of  the  system  or  subsystem.  One  method 
clearly  should  not  be  applied  across  the  board.  The  PM  should  consider  the  various 
alternatives  and  perfonn  analysis  to  detennine  the  best  approach  in  terms  of  meeting 
warfighter  demands  as  well  as  cost.  In  detennining  specific  support  solutions  for  a 
system  or  subsystem,  contractual  agreements  can  then  be  put  in  place  to  effectively 
manage  that  particular  system  or  subsystem. 

3)  Maintain  relationship  with  warfighter  to  the  extent  that  system  readiness  can  be 
continually  assessed  and  maintained. 

In  the  face  of  evolving  warfighter  capabilities  and  subsequently  new  development 
efforts  as  well  as  service  extension  of  existing  weapon  systems,  the  PM  must  strive  to 
keep  abreast  of  current  and  future  support  requirements.  Success  will  depend  on 
continual  communication  with  the  warfighter  in  addition  to  establishing  effective  support 
strategies. 

4)  Select  best-value,  long-term  product  support  strategies. 

In  an  effort  to  provide  the  best  performance  at  an  affordable  cost,  the  PM  must 
consider  all  available  support  options  and  attempt  to  coordinate  these  alternatives  into  a 
comprehensive  strategy  that  exhibits  “best-value”  over  predefined  periods  of  time. 

5)  Measure  support  performance  based  on  availability  of  mission  capable  systems, 
instead  of  on  distinct  elements  such  as  parts,  maintenance  and  data. 

Support  performance  directly  impacts  mission  capability.  The  support  strategy 
should  address  the  impact  of  support  on  mission  capability.  To  this  end,  availability 
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requirements  address  the  readiness  of  the  system.  Overall  system  availability  is 
dependent  on  the  distinct  elements  of  parts,  maintenance  and  data;  but  the  specifics  of 
these  are  not  adequate  for  clear  assessment  of  mission  capability.  That  is,  the 
mechanisms  of  the  support  alternatives  are  transparent  to  the  overall  objective  of 
supporting  the  warfighter.  The  support  options  are  considered  based  on  overall 
effectiveness  in  meeting  customer  capability  and  cost  expectations. 

6)  Improve  product  supportability,  system  reliability,  maintainability,  and 

supportability  via  continuous,  dedicated  investment  in  technology  refreshment 
through  adoption  of  performance  specifications,  commercial  standards,  non- 
developmental  items,  and  commercial-off-the-shelf  items  where  feasible,  in 
both  the  initial  acquisition  design  phase  and  in  all  subsequent  modification  and 
re-procurement  actions. 

This  goal  is  aimed  at  providing  the  warfighter  with  the  latest  supportable 
technology  in  an  effort  to  improve  weapon  system  performance.  This  is  perhaps  the 
greatest  challenge  the  PM  faces.  The  misalignment  of  DoD  acquisition  technology 
refresh  cycles  and  the  commercial  technology  update  cycles,  as  alluded  to  previously  in 
this  document,  pushes  the  PM  to  be  innovative  in  terms  of  supporting  COTS/NDI 
systems.  Ideally,  the  PM  would  like  to  redesign  or  refresh  a  system  in  order  to  provide 
greater  capabilities  to  the  warfighter  rather  than  due  to  obsolescence  or  diminishing 
material.  This  situation  must  be  dealt  with  for  all  phases  of  the  system  life  cycle. 

The  overarching  theme  of  DoDD  5000,  with  respect  to  supportability,  is  that 
product  support  is  part  of  the  Systems  Engineering  process.  And  a  key  component  of  this 
process  is  supportability  analysis.  Furthermore,  this  analysis  is  to  be  executed  throughout 
the  weapon  system  life  cycle  and  not  simply  confined  to  post-deployment.  The  analysis 
should  consider  reliability,  availability  and  maintainability  (RAM).  The  RAM  system 
requirements  cover  both  product  support  and  training  aspects.  These  elements  are 
derived  from  the  warfighter  readiness  requirements  and  shall  be  documented  in  a  well- 
planned  support  strategy.  [21)  DoD]  The  support  strategy  should  be  tailored  to  the 
specific  weapon  system  and  its  unique  characteristics  in  terms  of  COTS,  NDI,  and  MIL- 
Spec  mix  as  well  as  the  feasibility  of  particular  support  alternatives.  In  the  end,  the 
ultimate  goal  is  to  provide  the  warfighter  with  the  level  of  capability  readiness  they 
demand  in  the  most  cost-effective  manner.  And  since  supportability  is  a  major 
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component  in  meeting  this  requirement,  the  supportability  strategy  should  consider  all 
supportability  solution  alternatives  in  an  effort  to  deliver  a  “best-value”  approach. 
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VII.  ALIGNMENT  OF  STRATEGIC  BUSINESS  OBJECTIVES 

AND  GOALS 


In  this  section  we  attempt  to  align  the  objectives  and  goals  of  the  Sunset  Supply 
Base  (SSB)  system  with  DoD  objectives  and  goals.  The  purpose  here  is  to  see  how  the 
SSB  system  meets  the  needs  and  expectations  of  the  Navy’s  acquisition  process.  Prior  to 
any  analysis  it  is  important  to  ensure  that  the  system  under  study  is  appropriately 
addressing  the  concerns  or  deficiencies  found  within  the  targeted  environment.  In  this 
case  we  are  looking  at  how  the  SSB  objectives  fits  into  the  Navy  acquisition  process  and 
what  goals  it  can  help  fulfill.  Since  we  cannot  expect  a  one-for-one  alignment,  the 
approach  here  is  to  consider  how  each  objective  or  goal  of  the  SSB  fulfills,  in  some  part, 
the  objectives  and  goals  determined  for  the  agency  (DoD/Navy). 

A.  ALIGNMENT  OF  OBJECTIVES 

1.  Business  Case 

As  discussed  earlier  the  Navy  looks  to  the  Business  Case  for  making  decisions  on 
support  strategies  in  an  effort  to  provide  the  best  supportability  scenario  at  the  most 
affordable  level.  This  document  itself  serves  to  fulfill  this  objective.  A  business  case 
analysis  of  the  SSB  concept  is  to  be  performed  to  give  the  reader  an  understanding  of  the 
benefits  offered  and  at  what  costs.  Based  on  the  outcome  of  this  analysis,  one  of  the 
objectives  of  this  effort  is  to  promote  the  idea  of  the  SSB  architecture  as  a  viable, 
effective  and  valuable  alternative  based  on  costs  and  benefits.  Therefore,  keeping  in  line 
with  the  Navy’s  expectation  of  a  business  case  approach  to  determining  acceptance  of  an 
alternative,  a  case  will  be  made  for  the  SSB  system  based  on  both  tangible  and  intangible 
benefits  and  the  costs  to  achieve  them,  hopefully  leading  to  a  department  wide  adoption 
of  the  SSB  concept. 

2.  Product  Support 

The  Navy’s  objective  for  product  support  is  to  migrate  to  a  product  support 
strategy  that  is  based  on  output  measures  such  as  availability  of  weapon  system 
equipment,  an  enviromnent  that  offers  a  “best  value”  approach  to  fulfilling  warfighter 
demands.  In  essence,  the  Navy  is  looking  for  ways  to  improve  performance. 
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Performance  is  defined  by  how  well  a  support  strategy  meets  warfighter  supportability 
requirements  and  at  what  cost.  Of  course  there  is  always  a  trade-off  between 
performance  and  cost,  and  the  Program  Managers  (PM)  are  given  a  set  of  tools  to  manage 
this  performance/cost  relationship.  In  tenns  of  product  support,  the  PMs  have  at  their 
disposal  a  collection  of  alternatives  to  optimize  their  support  strategy.  As  part  of  its 
Strategic  Positioning  objective,  the  SSB  architecture  is  challenged  to  position  itself 
within  this  toolset  as  a  viable  alternative.  Furthermore  the  support  strategy  is  to  be 
applied  throughout  the  weapon  system  life  cycle;  the  ultimate  objective  being  the 
delivery  of  reliable  weapon  systems  that  can  be  cost-effectively  supported.  This  includes 
plans  for  initial  procurement,  re-procurement,  and  post-production  support. 
Understanding  these  demands,  the  PM  is  challenged  to  deliver  key  enabling  technologies 
that  must  be  supportable  for  fixed  periods  of  time.  The  SSB  infrastructure  is  driven  to 
provide  this  long-term  supportability  insurance.  In  fact,  as  part  of  its  objective  to 
positively  impact  Navy  supportability  functions,  the  SSB  process  is  geared  towards 
improving  program  supportability  by  extending  COTS  support  during  the  initial 
procurement,  re-procurement,  and  post-production  phases.  In  the  end,  for  weapon 
systems  that  have  deployed  COTS,  the  SSB  architecture  offers  an  opportunity  for 
supporting  these  existing  or  key  enabling  technologies.  In  the  end,  both  the  Navy 
acquisition  community  and  the  SSB  process  are  driven  not  only  to  optimize  the 
performance  of  supportability  and  sustainability  functions,  but  also  in  maintaining  key 
technologies.  So  in  tenns  of  product  support,  the  SSB  objectives  concur  with  the  Navy’s 
acquisition  expectations  with  respect  to  supporting  the  products  and  weapon  systems  in 
the  most  proficient  and  cost  effective  manner. 

3.  Life-Cycle  Management 

DoDD  5000  emphasizes  how  life-cycle  support  plays  a  critical  role  in  ensuring 
that  the  warfighter’s  requirements  are  met  throughout  the  life  cycle  of  the  weapon 
system.  As  mentioned  previously,  the  PM  should  have  at  their  disposal  a  set  of  product 
support  alternatives  to  optimize  this  effort  over  the  life  cycle  of  the  weapon  system. 
Again,  the  SSB  infrastructure  as  part  of  its  Strategic  Positioning  objective  hopes  to  make 
a  case  for  the  DoD  acquisition  policy  makers  as  to  the  benefits  of  including  this  process 
as  part  of  the  PMs  toolset  of  supportability  solution  alternatives.  In  tenns  of  enhancing 
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the  operations  and  functions  of  DoD  supportability  process,  the  SSB  process  has 
identified  as  an  objective  to  support  the  product  development  cycle  and  ultimately  the 
system  life  cycle.  In  particular,  the  SSB  process  focuses  on  maintaining  system  baseline 
stability  between  technology  refresh  dates  over  the  entire  life  of  the  weapon  system.  To 
this  end,  the  SSB  process  was  designed  to  have  positive  impacts  in  terms  of 
supportability,  program  planning,  and  program  risk,  with  the  objective  of  influencing 
improvements  in  the  life  cycle  management  of  the  program. 

4.  Cost 

The  Program  Management  Offices  (PMO)  are  guided  by  DoDD  5000  to  explore 
more  economical  alternatives  to  supporting  warfighter  requirements  with  the  overall 
objective  of  meeting  warfighter  demands,  in  terms  of  overall  capability,  at  an  affordable 
cost.  Again,  one  of  the  objectives  of  the  SSB  concept  is  to  offer  an  additional 
supportability  solution  alternative  for  improving  performance  in  supporting  the  weapon 
system,  including  quality,  at  lower  costs.  So  in  architecting  the  SSB  system,  the  intent 
was  to  not  only  have  positive  impacts  to  supportability,  program  planning,  and  program 
risk,  but  to  also  introduce  significant  reductions  in  Total  Ownership  Costs  (TOC). 

B.  ALIGNMENT  OF  GOALS 


The  following  table  presents  the  alignment  of  SSB  and  Agency  goals. 


Agency 

Goal# 

SSB  Goal(s) 

1 .  Integrate  supply  chains  to  achieve  cross-functional  efficiencies  and  provide  improved 
customer  service  through  performance-based  arrangements  or  contracts 

7 

A  system  that  leverages  Navy  and  commercial  supportability  assets  and 
provides  a  networked  solution. 

8 

Leverage  across  government  programs  with  extended  applicability  through 
contract  strategies,  methodologies,  and  incentives  to  entice  commercial 
industry  participation. 

2.  Segment  support  by  system  or  subsystem  and  delineate  agreements  to  meet  specific 
customer  needs. 

4 

Provide  infrastructure  to  support  existing  platform/combat  systems  in  support 
of  the  PMO 

5 

A  reliable,  affordable,  repeatable,  and  expandable  process  that  meets  the 
customer’s  performance  expectations  (e.g.,  accessible,  transportable, 
maintainable,  predictable). 
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Agency 

Goal# 

SSB  Goal(s) 

3.  Maintain  relationship  with  warfighter  to  the  extent  that  system  readiness  can  be 
continually  assessed  and  maintained. 

4 

Provide  infrastructure  to  support  existing  platform/combat  systems  in  support 
of  the  PMO 

5 

A  reliable,  affordable,  repeatable,  and  expandable  process  that  meets  the 
customer’s  performance  expectations  (e.g.,  accessible,  transportable, 
maintainable,  predictable). 

4.  Select  best-value,  long-term  product  support  strategies. 

1 

Achieve  significant  and  quantifiable  cost  savings  over  the  product  life  cycle 

3 

Extend  the  life  cycle  and  supportability  of  COTS. 

9 

Forecast  budget  requirements  in  support  of  the  programs/war 
fighter/consumer. 

5.  Measure  support  performance  based  on  availability  of  mission  capable  systems, 
instead  of  on  distinct  elements  such  as  parts,  maintenance  and  data. 

5 

A  reliable,  affordable,  repeatable,  and  expandable  process  that  meets  the 
customer’s  performance  expectations  (e.g.,  accessible,  transportable, 
maintainable,  predictable). 

6 

Institutionalize  methods  for  proactive  management  of  COTS  including 
DMSMS  issues 

6.  Improve  product  supportability,  system  reliability,  maintainability,  and  supportability 
via  continuous,  dedicated  investment  in  technology  refreshment  through  adoption  of 
performance  specifications,  commercial  standards,  non-developmental  items,  and 
commercial-off-the-shelf  items  where  feasible,  in  both  the  initial  acquisition  design  phase 
and  in  all  subsequent  modification  and  re-procurement  actions 

3 

Extend  the  life  cycle  and  supportability  of  COTS. 

6 

Institutionalize  methods  for  proactive  management  of  COTS  including 
DMSMS  issues 

9 

Forecast  budget  requirements  in  support  of  the  programs/war 
fighter/consumer. 

10 

Improve  schedule  flexibility  and  support  options  of  system  upgrades  or  new 
development  initiatives 

Appendix  C  Table  1:  Agency  and  SSB  Goal  Alignment 
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VIII.  SSB  PURPOSE 


By  defining  and  aligning  the  SSB  objectives  and  goal  with  the  objectives  and 
goals  of  the  DoD/Navy,  PMOs  we  can  better  focus  on  the  most  critical  aspects  of  the 
SSB  process  and  formulate  a  general  purpose  for  its  implementation.  Based  on  this 
alignment  we  conclude  that  the  overall  purpose  of  the  SSB  architecture  is  to  provide 
dependable,  cost  effective  supportability  insurance  for  COTS  based  weapon  and  support 
systems.  The  SSB  process  focuses  on  obsolescence  issues  and  material  shortages 
associated  with  COTS  usage  in  military  weapon  and  support  systems.  Addressing  these 
specific  areas,  the  SSB  provides  an  opportunity  to  extend  COTS  supportability  in  an 
effort  to  stabilize  the  weapon  system  baseline.  Success  is  driven  by  the  effectiveness  of 
the  SSB  process  to  assess  and  manage  COTS  technology  obsolescence.  The  key  to 
achieving  this  lies  with  the  ability  of  the  SSB  process  to  effectively  address  these  issues 
via  technology  obsolescence  forecasting  methodologies.  In  effect,  the  SSB  architecture 
provides  a  process  for  managing  changes  to  COTS  based  systems.  Figure  2  illustrates  the 
17-Step  Implementation  Process  and  when  combined  with  other  supportive  SSB 
infrastructure  tools,  methods  and  processes,  provides  a  continuous  review/mitigation  of 
DMSMS  issues.  Ultimately,  the  SSB  architecture  exists  to  respond  to  the  demands  of  the 
warfighter.  The  warfighter  requirements  are  communicated  to  the  PMO,  and  the  PMO  is 
tasked  to  develop  and  support  systems  that  provide  the  expected  combat  power.  As  part 
of  the  Systems  Engineering  process  the  PMs  develop  a  support  strategy  that 
accommodates  the  warfighter  requirements.  The  SSB  architecture  offers  a  support 
alternative  that  when  implemented  as  part  of  the  support  strategy,  adds  speed  and  agility 
into  the  supportability  process,  ultimately  providing  value  as  perceived  by  the  warfighter. 
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Appendix  C  Figure  2:  17  Step  Implementation  Process 
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IX.  GENERAL  APPROACH 


In  this  Business  Case  Analysis  (BCA)  we  will  address  various  supportability 
scenarios  in  tenns  of  overall  support  costs.  This  cost  is  comprised  of  procurement  costs 
and  the  resource  dollars  needed  to  implement  the  respective  scenario.  Cost  data  will  be 
considered  over  a  ten-year  support  period  for  the  Ship  Self-Defense  System  (SSDS). 
Each  scenario  will  be  evaluated  in  terms  of  overall  cost,  benefit  and  risk.  We  will  then 
focus  on  the  SSB  implementation  and  how  it  compares  to  the  other  scenarios  as  well  as 
how  well  it  fulfills  the  objectives  and  goals  stated  within  this  document.  In  terms  of 
evaluation  criteria,  we  will  look  at  funding  profiles,  initial  investments,  program 
flexibility  and  risk.  The  actual  costs  will  be  weighed  against  the  benefits  and  evaluated 
for  consistency  to  overall  DoD  guidance.  This  process  will  establish  clearly  defined 
financial  and  non-financial  benefits  of  the  SSB  implementation.  These  benefits  will  be 
matched  to  specific  SSB  process  goals.  The  goals  will  then  be  used  to  discuss  the 
contributions  to  the  SSB  objectives. 

A.  INTRODUCTION:  SITUATION  AND  MOTIVATION 

1.  Background 

In  this  section  we  will  identify  the  situation  and  motivation  factors  that  lead  to  the 
formulation  of  the  SSB  concept.  With  the  subject  and  purpose  clearly  defined,  it  is 
important  at  this  point  to  understand  the  context  of  this  BCA.  This  section  will  explore 
the  realities  associated  with  the  DoD/Navy  acquisition  process  in  terms  of  supportability. 
By  understanding  the  full  context  of  this  environment,  this  BCA  can  then  articulate  the 
results  and  recommendations  with  respect  to  the  main  points  presented  in  this  section. 

2.  Program  Management 

Per  the  guidelines  set  forth  in  DoDD  5000,  the  Program  Manager  (PM)  is 
challenged  to  develop  a  support  plan  that  takes  advantage  of  the  most  effective  methods 
in  supportability  while  meeting  specific  military  and  statutory  requirements.  In  this  way, 
the  PMs  can  optimize  both  performance  as  well  as  life  cycle  cost.  The  PM  has  the 
flexibility  and  authority  to  choose  from  a  set  of  solution  alternatives  (to  be  covered  later 
in  this  document).  Additionally,  the  PM  has  the  opportunity  to  choose  between  Organic, 
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internal  Navy  resources,  or  commercial  sources  of  supply.  The  important  thing  to 
understand  is  that  the  PM  has  reasonable  flexibility  in  the  effort  to  optimize  warfighter 
support.  The  primary  objective  is  to  achieve  maximum  weapon  system  availability  at  the 
lowest  Total  Ownership  Cost  (TOC).  One  initiative  to  achieve  these  objectives  is  the 
DoD  COTS  initiative.  The  general  inclination  is  that  in  both  the  private  and  public 
sectors,  COTS  has  been  able  to  reduce  costs  while  delivering  the  latest  technology. 
Unfortunately,  the  use  of  COTS  products  does  not  come  without  its  share  of  problems  (to 
be  discussed  in  greater  detail  later  in  this  document).  Nevertheless,  the  PMs  are  pushed 
to  consider  COTS  products.  The  primary  emphasis  behind  the  push  for  the  COTS 
initiative  is  the  speed  at  which  the  market  forces  can  deliver  the  latest  technology. 
Subsequently,  many  Request  for  Proposals  (RFPs)  issued  by  the  Program  Management 
Offices  (PMO)  demand  a  certain  level  of  COTS  usage  in  the  system.  [17)  Carney- 
Obemdorf]  This  expectation  is  echoed  by  DoD  policy  makers  who  have  instituted 
policies  for  using  COTS  products  as  much  as  possible.  Needless  to  say,  the  proliferation 
of  COTS  products  in  military  systems  has  increased  over  the  years.  This  increase  has 
also  lead  to  an  increase  in  the  number  of  required  product  upgrades  and  technical 
refreshes  within  a  system.  Some  of  the  problems  that  the  PMOs  have  had  to  manage 
include  obsolescence,  meeting  new  performance  requirements,  and  implementation  of 
more  cost  effective  support  strategies.  Typically,  these  problems  are  met  with 
engineering  changes  that  tend  to  be  costly.  In  reality,  what  is  needed  is  a  more  phased 
technology  management  approach.  An  approach  which  provides  three  main  elements: 

•  The  ability  to  assess  the  technical  and  supportability  status  of  current 
equipment.  This  includes  equipment  selected  in  the  design  phase  as  well. 

•  The  ability  to  recognize  potential  supportability  problems  and  recommend 
support  solution  alternatives. 

•  The  ability  to  determine  the  costs  of  implementing  these  support-solutions 
over  a  specific  period  of  time. 

This  process  of  technology  assessment  should  play  a  critical  part  of  the  overall 
life  cycle  management  of  military  weapon  systems.  The  information  and  knowledge 
derived  from  this  process  will  ultimately  improve  system  integration,  product 
replacement,  upgrades,  and  technology  insertions  of  weapon  systems  that  are  comprised 
of  both  military  build-to-print  equipment  and  COTS  products.  Given  the  variability  of 
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Mil-Spec  and  COTS  product  usage,  the  PM  has  options  as  to  source  of  support,  organic 
or  commercial.  Armed  with  the  knowledge  derived  from  the  technology  assessment 
process,  the  PM  can  make  better  decisions  on  source  of  support  selection  that  effectively 
optimizes  supportability  perfonnance  and  Life  Cycle  Costs  (LCC).  In  this  way,  the  PMs’ 
actions  are  consistent  with  military  and  statutory  requirements  for  using  the  most 
effective  means  available  for  providing  maximum  weapon  system  availability  at  the 
lowest  TOC. 

3.  Production  /  Sustaining  Support 

With  regards  to  supporting  COTS  products,  two  concepts  are  important  to 
understand  that  have  motivated  the  inception  of  the  SSB  concept.  They  are  Sustainment 
Engineering  and  producibility. 

Sustainment  Engineering  -  This  refers  to  the  ability  of  sustaining  a  system  for  its 
entire  life.  Currently  sustainment  engineering  focuses  on  design  for  test  and  reliability, 
and  the  ability  to  repair  in  order  to  meet  availability  requirements.  With  the  onset  of 
COTS  products  in  military  weapon  systems,  the  task  of  exercising  these  functions 
becomes  difficult.  Typically,  addressing  supportability  issues  associated  with  COTS 
products  takes  on  a  reactive  stance.  Re-designs  are  initiated  reactively  upon  receipt  of 
obsolescence  or  the  End  of  Life  (EOL),  End  of  Production  (EOP)  notice.  That  is,  little  is 
done  in  terms  of  re-design  until  the  COTS  product  has  been  officially  labeled  obsolete. 
Therefore,  traditional  sustainment  engineering  efforts  have  become  incredibly  difficult  to 
perform  without  some  insight  into  future  technology  trends.  The  DoD  Acquisition 
Deskbook  provides  the  Flexibile  Sustainment  Guide,  which  provides  guidance  to  PMs  for 
“...translating  mission  needs  into  stable,  affordable  and  well-managed  acquisition 
programs... ”[23)  DoD]  The  guide  strongly  urges  the  use  of  an  open  architecture 
approach  to  designing  future  weapon  systems.  The  idea  being,  that  future  upgrades  could 
be  easily  and  cost  effectively  implemented  if  adherence  to  perfonnance-based  standards 
are  maintained.  The  approach  is  a  tremendous  leap  in  managing  DoD  programs  and  its 
complete  fruition  should  be  realized  years  from  now.  But  many  current  efforts  are  still 
struggling  with  implementing  open-system  architectures  due  to  the  unique  requirements 
of  the  military.  Suffice  it  to  say  COTS  products  have  provided  some  benefit  in  terms  of 
delivering  technology  affordably,  but  the  supportability  issues  that  come  with  trying  to 
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sustain  a  COTS-based  system,  between  periods  of  technology  refresh,  have  not  been 
completely  solved. 

Producibility  -  In  the  traditional  sense,  producibility  is  a  measure  of  the  relative 
ease  of  manufacturing  a  product.  Typically,  this  means  how  easy  is  the  item  produced 
from  a  technical  standpoint.  In  tenns  of  sustainment,  we  use  producibility  to  refer  to  a 
company’s  commitment  and  capability  in  manufacturing  a  product  in  an  acceptable 
quantity  with  an  expected  high  degree  of  quality  and  reliability.  In  looking  at  major 
weapon  systems,  one  can  only  imagine  the  diversity  of  MIL-Spec  and  COTS  products 
used  within  a  particular  system.  From  the  PMs’  perspective,  support  budget 
appropriations  and  control  is  profoundly  complicated.  Additionally,  support  engineering 
management  is  difficult  as  well,  when  one  considers  the  likeliness  that  a  program  in  the 
design  phase  will  be  supported  from  several  different  sources.  To  further  complicate  the 
situation,  the  various  sources  of  supply  are  autonomous  groups.  This  situation  usually 
leads  to  poor  communication  between  the  sources  of  supply  and  DoD/Navy  on  support 
issues.  The  PM  must  rely  on  engineering  support  activities  to  pull  the  issues  of  support 
and  producibility  together  in  order  to  accurately  assess  program  direction.  This  function 
is  important  given  the  interdependence  of  items  in  a  system.  In  general  terms,  if  a  change 
is  made  to  one  item,  due  to  upgrade  or  obsolescence,  the  PM  needs  to  understand  the 
impact  this  will  have  to  other  MIL-Spec  or  COTS  items.  The  problem  grows  when  we 
consider  the  chance  that  impacted  items  may  not  be  easily  producible.  So  we  see  that 
producibility  is  important  because  we  have  to  make  sure  that  whatever  changes  take 
place,  we  fully  understand  the  impacts,  and  that  we  can  maintain  producibility  of  the 
system.  Presently,  producibility  efforts  remain  largely  unorganized.  Given  this  situation 
a  supportability  assessment  mechanism  is  needed  in  order  to  help  PMs  stabilize  their 
system  baselines.  The  critical  information  derived  from  such  assessment  will  provide 
cost  and  schedule  impact,  and  availability  of  critical  material  and  equipment.  The  present 
situation  is  one  of  minimal  producibility  engineering  activities.  Typically,  support  issues 
are  managed  by  the  respective  engineering  or  support  organization.  In  effect  what  occurs 
is  that  the  burden  to  ensure  the  system  is  producible  or  supportable  is  on  the  In-service 
Engineering  Agent  (ISEA)  for  that  system.  A  daunting  task  to  say  the  least,  given  the 
necessity  for  numerous  Engineering  Change  Proposals  (ECP)  associated  with 
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obsolescence.  One  should  realize  that  ECPs  lead  to  re-designs,  which  typically  translates 
to  increased  costs  and  delays  in  schedule.  This  environment  is  a  driving  element  for 
conceptualizing  a  process  that  can  mitigate  the  risk  of  having  to  re-design  for  reasons  of 
obsolescence.  In  the  end,  some  attention  must  be  given  to  maintaining  production  of 
certain  key  products  for  the  duration  between  scheduled  technology  refresh  dates. 

4.  Interoperability  and  Configuration  Control 

Interoperability  through  open  systems  architecture  is  not  something  that  has  come 
to  full  fruition  with  respect  to  military  weapon  system  implementation.  Military  systems 
typically  have  very  unique  or  stringent  requirements  that  only  very  specific  products  can 
fulfill.  To  add  to  this,  the  systems  or  subsystems  are  so  sensitive  to  change  that  an  open- 
systems  architecture  is  presently  difficult  to  implement.  If  every  system  and  subsystem 
could  be  redesigned  using  an  open-systems  approach,  true  interoperability  could  perhaps 
be  achieved.  Unfortunately,  this  is  not  the  case.  In  fact,  open-system  architectures, 
although  established  as  a  goal  for  many  DoD  programs,  will  experience  an  extremely 
slow  transition  primarily  due  to  funding.  In  the  mean  time,  fielded  systems  as  well  as 
those  presently  under  development  that  are  using  COTS  products  must  be  assured  of 
supporting  these  items  leading  to  a  stabilized  system  baseline  between  periods  of  update 
or  technology  refresh.  The  importance  of  this  cannot  be  understated,  given  the 
certification  requirements  that  every  system  must  meet  before  it  is  put  into  operation. 
The  hope  of  true  interoperability  is  a  lofty  goal,  considering  how  tightly  software  and 
hardware  are  grown  dependent  over  the  years.  Given  this  situation,  it  is  not  hard  to  see 
how  a  simple  hardware  change  could  easily  require  changes  to  system  software  code. 
COTS  hardware  changes  regardless  of  impact  to  military  applications.  Remember, 
COTS  product  changes  are  driven  by  the  market  in  which  the  DoD  only  maintains 
approximately  a  0.4%  market  share.  Additionally,  the  proliferation  of  COTS  throughout 
military  weapon  and  support  systems  results  in  a  lack  of  control  over  the  configuration  of 
these  products.  By  not  possessing  the  design  or  having  access  to  a  design  disclosure,  the 
PMOs  cannot  provide  insurance  to  the  warfighter  that  the  present  system  design  will  be 
stabilized  or  can  effectively  be  supported  for  some  pre-detennined  period  of  time. 
Without  this  control,  the  PM  will  unlikely  be  aware  of  changes  in  manufacturers’  product 
specifications.  For  commercial  customers  it  may  be  adequate  to  simply  define  the  inputs 
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and  outputs  in  product  specifications.  However,  military  applications  have  been  built 
around  closely  coupled  software  —  minor  changes  to  a  piece  of  hardware  using  embedded 
firmware  could  conceivably  result  in  thousands  of  hours  of  software  engineering,  testing 
and  re-certification.  This  further  emphasizes  the  need  for  control  over  the  configuration 
management  of  COTS  products.  The  present  situation,  in  terms  of  interoperability  and 
configuration  control,  assumes  or  depends  on  the  openness  or  robustness  of  these  systems 
to  handle  potential  changes  to  COTS  products.  Nevertheless,  the  sensitivity  of  presently 
fielded  weapon  systems  to  minor  changes  illustrates  the  importance  of  stable  COTS 
product  configurations  for  effective  support  of  these  military  systems. 

5.  Performance  Based  Logistics 

Performance  Based  Logistics  (PBL)  is  an  initiative  undertaken  by  the  Naval 
Inventory  Control  Point  (NAVICP)  in  an  effort  to  improve  support  as  well  as 
infrastructure  and  TOC  for  Navy  weapon  and  support  systems.  The  focus  is  on 
improving  customer  support  and  total  LCC  management  where  customer  input  initiates  a 
network  of  sources  for  delivering  “best  value”  products  and  services.  The  primary 
objective  is  to  improve  the  availability  and  reliability  of  products  that  are  provided  to  the 
warfighter. 

Concept  -  Contracts  are  awarded  to  specific  suppliers  that  are  then  responsible  for 
delivering  products  directly  to  the  warfighter.  All  material  is  managed  and  stored  by  the 
supplier  with  little  government  intervention.  This  situation  reduces  the  associated  costs 
to  the  government.  Each  contract  is  unique  depending  on  products  and  services  that  are 
required  by  the  DoD  and  offered  by  the  supplier.  The  contracts  are  for  specific  periods  of 
time  in  which  the  product  and  services  are  needed.  Each  potential  arrangement  is 
evaluated  through  a  BCA  in  order  to  detennine  the  full  value  of  the  PBL  contract.  Each 
case  is  considered  for  its  cost  reduction  and/or  cost  avoidance  measures.  The  basis  of 
PBL  is  in  establishing  logistics  performance  requirements  and  contractual  incentives  to 
mitigate  obsolescence  and  lower  the  LCC. 

Process  -  PBL  proposes  that  all  logistical  support  be  incorporated  into  a 
performance-based  business  environment.  An  environment  where  commercial  and 
Organic  (government)  capabilities  are  assessed  and  compared  to  specific  logistical 
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requirements  of  the  Navy  for  determining  “best  value”.  The  PBL  concept  incorporates 
direct  vendor  delivery,  technology  insertion,  reliability-centered  maintenance,  process 
improvement,  business  reengineering,  public/private  partnering  and  teaming.  The  PBL 
concept  is  applied  to  both  fielded  weapon  systems  as  well  as  new  acquisitions.  In  this 
process  a  single  supplier  provides  all  of  the  required  products  and  services  to  the 
warfighter.  All  material  management,  storage,  and  handling  is  accomplished  by  this  one 
supplier  with  little  or  no  government  intervention.  These  contractual  arrangements 
promise  to  improve  availability  at  lower  TOC.  To  what  degree,  depends  again  on  the 
preferred  arrangement.  Figure  3  offers  typical  PBL  arrangements.  [24)  NAVICP] 

Typical  PBL  Arrangements 

PBL-Mini-Stock  Point  (PBL-MSP).  Navy  owns  the  inventory... contractor 
receives,  stores,  issues,  and  may  also  repair,  the  material...  “MSP-Plus”  includes  a 
negotiated  level  of  requirements  determination  (MIN/MAX). 

PBL-Organic  (PBL-O).  An  arrangement  with  an  organic  activity  (normally  via 
MO  A)  to  procure,  repair,  stock  and  issue  material. 

PBL-Commercial  (PBL-C).  An  arrangement  where  a  contractor  supplies 
commercial  items.  Customer  requisitions  are  automatically  routed  through  ITIMP 
directly  to  the  contractor  as  a  delivery  order. 

PBL-Partnership  (PBL-P).  An  arrangement  between  a  contractor  and  Navy 
such  that  the  Navy  performs  a  portion  of  support  required  by  and  for  the  contractor.  For 
example,  the  contractor  may  sub-contract  the  Navy  to  perform  maintenance  support  at  an 
organic  depot.  This  can  be  highly  beneficial  when  addressing  Core  maintenance  issues, 
in  that  the  Navy  is  able  to  retain  Core  capability  while  acting  as  a  “sub”  to  the  contractor. 

“Full”  PBL.  A  contractual  arrangement  where  the  contractor  manages  (and  may 
also  own)  the  inventory,  determines  stockage  levels,  typically  repairs  NRFI  material,  and 
is  required  to  meet  specific  performance  metrics.  Requisitions  still  flow  through  ICP, 
and  ICP  pays  the  contractor  for  performance  but  bills  customers  traditionally.  Reliability 
improvements,  technology  insertion  and  reduced  obsolescence  may  be  some  of  the 
inherent  benefits  of  a  Full  PBL.  The  contractor  usually  is  given  Class  II  ECP  authority 
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and  in  some  cases  may  also  have  configuration  control.  Additionally,  Logistics 
Engineering  Change  Proposal  (LECP)  arrangements  will  be  considered  a  subset  of  this 
category  if  they  contain  supply  support  clauses  that  fall  under  the  definition  noted  above. 

Total  Logistics  Support.  A  most  robust  form  of  PBL  (typically  referred  to  as 
Contractor  Logistics  Support  (CLS)),  where  the  contractor  manages  most  or  all  facets  of 
logistic  support  (i.e.  ILS  elements),  including  inventory  levels,  maintenance  philosophy, 
training  manuals,  PHS&T,  full  configuration  control,  support  equipment,  etc. 


Appendix  C  Figure  3:  Typical  PBL  Arrangements 

Characteristics  -  As  mentioned  in  the  previous  paragraph,  the  contractor,  through 
a  PBL  arrangement,  performs  selected  govermnent  functions  such  as  supply  support, 
repair,  sparing,  obsolescence  management,  etc.  In  effect,  the  supplier  has  assumed  some 
of  the  risks  traditionally  borne  entirely  by  the  DoD.  Under  the  PBL  process  the 
contractor  guarantees  improved  availability  and  reliability.  Contractors  are  given  more 
flexibility  and  control  in  configuration  management.  In  the  end,  life  cycle  costs  are 
expected  to  be  reduced  by  initiating  fixed  price  contracts  that  have  incentives  for  the 
contractor  to  show  cost  savings  while  improving  reliability  and  availability.  Fixed  price 
contracting  is  arranged  to  support  a  forecasted  demand  over  a  specific  period  of  time, 
usually  five  years.  During  this  period,  the  contractor  is  primarily  accountable  for 
performance.  This  assumption  of  risk  on  the  part  of  the  contractor  means  a  “letting  go” 
of  some  control  by  the  DoD. 

6.  Sunset  Supply  Concept 

Presently,  the  Sunset  Supply  Base  concept  is  being  implemented  on  three 
programs: 

•  Ship-Self  Defense  System  Mkl  (NAVSEA) 

•  Ship-Self  Defense  System  Mk  2  (NAVSEA) 

•  AN/AQS-20X  Sonar  Mine  Detecting  Set  (NAVSEA) 

The  PMs  for  each  of  these  programs  have  entered  into  this  collaborative 
environment  for  ensuring  long-term  product  support  and  the  potential  cost  savings  that 
this  process  offers.  This  process  requires  involvement  between  government  (PMOs  and 
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Navy  field  activities)  and  industry  (DoD  system  integrators,  COTS  OEM  vendors,  and  - 
where  applicable  -  Sunset  Suppliers).  The  broad  objective  of  this  process  is  a  proactive 
planning  and  coordination  effort  that  is  focused  on  extending  the  life  of  high  quality, 
complex  COTS  products.  This  is  achieved  by  essentially  extending  the  capability  to 
build  the  product  for  defined  periods  of  time.  The  net  result  is  a  reduction  in  cost  in 
terms  of  system  sustainment.  The  key  to  success  is  the  proactive  planning  that  goes  into 
establishing  reasonable  product  support  timelines  rather  than  reacting  to  changes  to  the 
COTS  product.  By  implementing  the  SSB  infrastructure,  the  PMs  are  seeking  the 
following: 

•  Supportability  of  products  defined  by  customer  need,  (5,  10,  15,  20  years) 

•  Life  cycle  cost  savings,  due  to  no  lifetime  buy  at  the  assembly  level.  The 
assemblies  are  procured,  as  the  customer  requires  them. 

•  Reparability  of  assemblies  over  the  designated  life  cycle  (5,  10,  15,  20  years) 

•  Hardware/Software/Finnware  stability  between  technology  refresh  dates. 

•  Significant  reduction  in  program  risk  as  related  to  COTS  and  life  cycle 
management 

•  Improved  schedule  flexibility  and  support  options  that  can  be  tailored  around 
warfighter  requirements. 

•  Minimal  or  no  impact  on  system  operational  performance.  Since  the  product 
will  continue  to  be  supported  in  its  original  form,  fit,  and  function,  there 
should  be  no  impact  to  performance.  These  products  will  continue  to  be 
produced  by  the  Sunset  Supplier. 

The  infrastructure  for  the  SSB  process  is  well  thought  out  and  structured  in  such  a 
way  as  to  allow  for  growth  capability.  A  Systems  Engineering  Development  and 
Implementation  (SEDI)  Plan  for  the  SSB  infrastructure  has  been  developed  to  put  into 
perspective  the  processes,  methods  and  tool  needed  to  implement  the  Sunset  Supply  Base 
(SSB)  system.  The  resulting  infrastructure  is  designed  to  fulfill  the  objectives  and  goals 
previously  described.  The  essence  of  the  process  is  to  provide  the  interface  management 
for  long-term  COTS  supportability.  In  doing  so,  long-term  relationships  are  established 
in  an  environment  that  preserves  and  protects  the  intellectual  property  rights  of  the  OEM 
and  business  objectives  of  the  Sunset  Supplier.  The  infrastructure  presented  in  the  SEDI 
plan  is  composed  of  two  functional  areas;  (1)  programmatic  support,  and  (2) 
infrastructure  support.  A  brief  outline  of  the  functions  and  tasks  taken  from  the  SEDI 
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plan  is  provided  in  Figures  4  and  5.  Implementation  of  the  SSB  infrastructure  essentially 
establishes  and  empowers  a  support  team  that  strives  to  meet  the  goals  and  objectives 
previously  stated.  Based  on  these  goals,  the  team  is  responsible  for  ensuring 
expandability,  transportability,  reusability,  leveraging  capability,  configuration  manage¬ 
ment  and  control,  affordability  and  LCC  assessments.  Important  to  understand  is  that 
these  functions  are  embedded  within  the  SSB  process  and  are  not  duplicated  anywhere 
within  the  infrastructure. 

_ Programmatic  Support _ 

Programmatic  Functions: 

1 .  Interface  with  the  PMO  &  Infrastructure  Team 

1.1.  Details  pertaining  to  specific  program  characteristics  - 

1.1.1.  Number  of  systems 

1.1.2.  Number  of  COTS  assemblies  used  and  where 

1.1.3.  Insight  into  the  prime  contractors  assembly  call  out 

1.1.4.  Reliability  numbers  (i.e.  failure  rates,  MTBF,  etc.) 

1.1.5.  Fielded  systems  concept  of  deployment  and  operation 

2.  Provide  Recommendations 

2.1.  Buy  quantities 

2.2.  Technology  refresh  intervals  and  interim  support  strategies. 

Programmatic  Tasks: 

3.  Obsolescence  reporting 

4.  Provide  purchase  recommendations 

5.  Interface  with  OEM,  SSB  supplier  and  PMO  support  teams 

6.  Involvement  in  applicable  program  activities 

7.  Identify  and  implement  program  specific  flow-down  requirements 

8.  Address  quality  issues  (hardware/software,  documentation,  etc.)  and  interface 

with  the  OEM,  SSB  supplier,  PMO,  prime  contractor,  etc. 

9.  Cost  assessment  based  on  LCC  and  the  unique  opportunity  to  impact  these  costs 

_ through  implementation  of  the  SSB  system. _ 

Appendix  C  Figure  4:  Programmatic  Support 
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_ Infrastructure  Support _ 

Infrastructure  Functions: 

10.  Interface  with  the  programmatic  POCs 

1 1 .  Establish  and  maintain  the  OEM/SSB  supplier  relationships 

12.  Develop  a  database  with  appropriate  controls  and  access  rights 

12.1.  Creation  of  the  database  structure 

12.2.  Define  methods  for  updating  data  and  controlling  access  rights 

12.3.  Provide  mechanisms  for  continuous  maintenance 

13.  Provide  a  central  site  to  enable  open  and  private  communication  (i.e.  specific 
server  location,  web  site,  bulletin  board,  etc.) 

14.  Perform  analysis  on  the  data  gathered 

15.  Coordinate  with  all  support  activities  where  applicable  (ISEA,  TDA,  etc.) 

16.  Report  findings  or  status 

17.  Coordinate  with  other  programs  that  could  be  affected  by  the  reporting  results 

18.  Perform  on-site  reviews  at  the  SSB  suppliers  to  assure  schedule,  cost  and  quality 

performance  is  maintained. 

Infrastructure  Tasks: 

19.  Database  Management 

19.1.  Program  generated,  prioritized,  Costs  lists,  at  the  assembly  level 

19.2.  OEM  provided,  component  piece  parts  lists  and  drawings  detailing  the 
make-up  of  the  assembly  level:  Cautionary  Note  -  These  parts  lists  and 
drawings  supplied  through  the  OEM  are  obtained  through  entering  a  Non- 
Disclosure  Agreement  (NDA)  and  therefore  necessitates  special  handling 
along  with  restricted  access. 

19.3.  Development  of  a  relational  database;  Design,  Management,  and 
Maintenance 

19.4.  Informational  query  and  data  extraction 

20.  Obsolescence  Risk  Management 

20. 1 .  Receive  COTS  assemblies  list  from  programmatic  POC 

20.2.  Perform  assembly  level  obsolescence  health/risk  at  that  level 

20.3.  Retrieve  from  the  COTS  OEMs  the  component  piece  parts  list  for  each 
assembly. 

20.4.  Filter  the  component  piece  parts  list  and  condense  list  to  active 
components  for  which  predictive  obsolescence  tool  are  readily  available  and 
used  as  industry  standards.  Exceptions  to  this  filtering  process  are  handled  on 
a  case-by-case  basis. 

20.5.  Perform  a  piece  part  level  obsolescence  health/risk  analysis  at  the 
component  piece  part  level. 

20.6.  Prepare  an  Obsolescence  Risk  Report  for  the  program  in  an  agreed  upon 
format,  by  working  with  the  programmatic  POC 

20.7.  Perform  continuous  monitoring  of  the  component  piece  parts  by  reviewing 
impact  of  ongoing  obsolescence  notices  posted  by  the  component  piece  part 
manufacturers. 

2 1 .  Initiate  the  relationship  with  the  Original  Equipment  Manufacturers  (OEM)  and 
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_ Infrastructure  Support _ 

act  as  the  primary  interface  with  them  throughout  the  life  of  the  SSB  system. 

22.  Initiate  the  relationship  with  the  SSB  suppliers  and  act  as  the  primary  interface 
with  them  throughout  the  life  of  the  SSB  system  and  perform  on-site  reviews  of 
SSB  suppliers  using  an  IEEE  1722  type  evaluation. 

23.  Interface  as  required  with  other  program  support  activities  (i.e.  ISEA,  ILS,  TDA, 
etc.) 

24.  Teaming  with  the  programmatic  POC  and  the  other  program  support  activities, 
define  and  document  the  expectations  and  required  support  from  the 
infrastructure  team.  Typically  these  expectations  and  requirements  are  embedded 
in  a  Statement  of  Work  (SOW),  a  tasking  document,  or  in  a  Memorandum  of 
Understanding  (MOU)  between  the  implementing  activity  and  the  PMO. 
Examples  of  these  types  of  documents  are  available  in  Enclosure  (9)  -  “Tasking 
Documentation”. 

25.  As  opportunities  emerge,  the  infrastructure  team  is  responsible  for  the  interface 
with  other  activities  such  as  other  field  activities,  professional  societies, 
government  initiatives,  industry  working  or  focus  groups,  etc.  that  provide 

_ potential  improvements  or  impacts  to  the  SSB  system  and  its  implementation. 

Appendix  C  Figure  5:  Infrastructure  Support 


C.  PROBLEM  DESCRIPTION 

This  section  will  describe  the  problem  of  supporting  COTS  products  within  the 
context  detailed  in  the  previous  section.  A  thorough  understanding  of  the  problem  to 
which  the  SSB  concept  applies,  will  help  in  evaluating  the  overall  effectiveness  of 
implementing  the  SSB  infrastructure. 

1.  Economic  Problem 

The  current  DoD  requirements  include  a  scenario  of  increased  operations  while  at 
the  same  time  a  continuous  push  for  weapon  system  upgrades.  The  easy  solution  would 
be  to  increase  the  defense  budget,  although  not  very  likely.  Given  the  political  pressures 
of  today,  DoD  PMOs  are  challenged  to  search  for  more  economical  alternatives.  The 
challenge,  in  effect,  is  to  maintain  near-tenn  weapon  system  readiness  while  at  the  same 
time  planning  for  weapon  system  modernization  efforts.  To  add  to  this,  the  DoD  is 
undergoing  a  serious  reduction  in  government  infrastructure.  Given  the  current  trend  of 
increasing  military  operating  tempos,  the  struggle  to  accomplish  any  sort  of 
modernization  effort  is  going  to  be  difficult.  In  fact,  financial  resources  are  likely  to  be 
used  to  maintain  these  levels  of  operations  rather  than  conducting  serious  modernization 
efforts.  The  Joint  Aviation  Logistics  Board  (JALB)  June  1999  report  on  Commercial 
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Support  of  Aviation  Systems  states  that  “...discretionary  procurement  accounts  dropped 
by  53  percent  since  1990,  while  operations  and  maintenance  activity  declined  by  only  15 
percent”.  [25)  JALB]  The  implication  of  this  statement  is  that  replacement  or  upgrades 
to  existing  systems  are  effectively  being  delayed.  [26)  JACG]  Secretary  of  Defense 
William  Cohen,  in  the  May  1997  Report  of  the  Quadrennial  Defense  Review,  observed 
that  “Today,  the  Department  is  witnessing  a  gradual  aging  of  the  force.”  [19)  DoD]  This 
lends  credence  to  the  statement  in  a  1994  issue  of  Army  RD&A  Bulletin :  “In  actuality,  our 
military  hardware  is  now  on  a  replacement  cycle  of  about  54  years  -  this  in  a  world  where 
technology  typically  has  a  half-life  from  2  to  10  years.”  [7)  Augustine]  The  end  result  is 
that  existing  systems  will  have  to  be  maintained  at  the  required  levels  of  availability  and 
reliability  for  extended  periods  of  time.  Therefore,  traditional  support  strategies  will  have 
to  be  re-evaluated  to  address  this  phenomenon.  These  traditional  strategies  typically 
expect  total  government  ownership  of  support  material  and  total  government  control  over 
design  changes.  What  this  has  leaded  to  is  known  as  the  COTS  initiative.  The  emphasis 
on  COTS  product  usage  was  brought  on  by  the  fact  that  the  DoD  could  conceivably  take 
advantage  of  technology  developments  in  the  commercial  sector  at  a  reduced  cost  to 
development  programs.  So  given  the  fact  that  more  and  more  of  the  defense  budget  is 
going  to  sustainment  of  operations,  the  financial  resources  needed  to  modernize  existing 
weapon  systems  is  decreasing.  So  to  reiterate,  more  economical  solutions  to  supporting 
these  systems  is  needed  and  one  initiative  is  the  growing  use  of  COTS  products 
throughout  DoD  weapon  and  support  systems.  With  COTS  products  come  additional 
challenges  in  support,  given  the  fast  paced  technology  update  cycles  in  the  commercial 
sector  as  compared  to  the  slow  and  methodical  DoD  acquisition  process.  Thus,  there  is 
an  anticipated  increase  in  material  or  product  obsolescence.  So  the  savings  realized  by 
implementing  an  aggressive  COTS  initiative  could  be  offset  by  obsolescence  and  the 
need  to  redesign.  This  is  not  to  say  that  COTS  products  have  not  proved  beneficial,  on 
the  contrary,  but  the  overall  process  for  incorporation  and  sustainment  of  COTS  products 
continues  to  evolve  and  PMs  continue  to  be  confronted  with  certain  challenges  associated 
with  this.  Therefore,  a  solution  alternative  is  needed  to  counteract  the  costs  associated 
with  the  redesign  of  weapon  and  support  systems  due  to  obsolescence  rather  than 
performance. 
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2. 


Sustainment  Problem 


The  COTS  initiative  was  brought  about  by  the  fact  that  the  commercial  sector 
essentially  drives  technology  change  at  an  extremely  fast  pace  and  that  the  DoD  could 
take  advantage  of  this  while  reducing  life  cycle  costs.  The  COTS  initiative  provided  a 
potential  path  to  infuse  new  technology  into  the  military  systems  and  at  the  same  time 
avoid  the  developmental  costs  associated  with  grooming  the  new  technology.  The  rate  at 
which  private  industry  can  develop  and  deliver  new  technologies  is  orders  of  magnitudes 
faster  than  traditional  DoD  acquisitions.  Take  a  look  at  computing  power,  which  has 
appeared  to  double  every  eighteen  months.  The  same  phenomenon  has  occurred  across 
the  spectrum  of  technology  at  different  rates.  Market  forces  other  than  the  DoD 
essentially  drive  this  explosion  of  new  capabilities.  The  DoD  makes  up  approximately 
0.4%  of  the  market  share  [4)  Hartshorn];  therefore;  it’s  not  hard  to  see  how  commercial 
product  lines  are  driven  by  the  private  sector  vice  the  DoD.  There  are  two  fundamental 
reasons  for  this  fast  pace.  One  is  the  ever-increasing  demand  for  new  capabilities 
primarily  in  the  private  domain.  Second,  the  competitive  drive  to  get  technology  to 
market  first  and  gain  the  most  lucrative  share  of  the  market.  In  either  case,  the  DoD  has 
little  influence.  Original  Equipment  Manufacturers  (OEM)  routinely  stop  production  on 
items  that  can  no  longer  be  justified  from  a  business  perspective  regardless  of  the  impact 
to  the  DoD.  The  typical  length  of  time  a  product  can  be  considered  available  is 
approximately  18-24  months.  That  is  to  say,  manufacturers  are  developing  and  releasing 
new  capabilities  every  18  months  to  2  years.  In  contrast,  DoD  weapon  system 
acquisitions  typically  take  10  to  15  years  to  develop  and  fully  deploy.  At  a  very 
minimum,  the  DoD  can  presently  only  hope  to  achieve  technology-refresh  cycles  of  5 
years,  which  is  still  not  adequately  aligned  with  commercial  product  updates.  See  Figure 
6  for  a  pictorial  representation  of  this  phenomenon. 
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Appendix  C  Figure  6:  Technology  Refresh  Timing 

When  we  say  fully  deploy,  we  mean  that  even  though  a  weapon  system  is  ready  to 
be  installed,  each  platform  for  installation  must  be  scheduled  to  receive  it.  Even  if  we 
consider  an  aggressive  development  effort  within  the  Navy,  the  time  to  develop  a  new  or 
enhanced  capability  could  easily  take  5  to  7  years.  Once  the  weapon  system  has  been 
tested  and  deemed  ready  for  deployment,  it  will  take  additional  5  to  10  years  to  fully 
deploy.  Every  platfonn  or  ship  that  is  to  receive  this  weapon  system  must  be  scheduled 
and  the  work  to  install  performed.  Ship  deployment  schedules  and  the  length  of 
availabilities  (in-port  period  when  the  work  is  performed)  add  serious  delays  to  installing 
the  weapon  system.  It  is  simply  inconceivable  to  think  that  new  technology,  which  is 
turning  over  every  18  months,  can  be  infused  consistently  throughout  the  fleet.  Of 
course,  its  possible  to  have  different  platforms  upgraded  to  different  levels  of  capability, 
but  then  we  run  the  risk  of  incompatibility  between  platforms  and  a  logistical  nightmare 
in  supporting  various  versions  of  the  same  weapon  system.  What  this  all  comes  down  to, 
in  terms  of  COTS,  is  a  decrease  in  DoD  control  over  weapon  system  design  and 
subsequent  support.  The  purpose  here  is  not  to  discredit  the  COTS  initiative  as 
ineffective.  The  COTS  initiative  in  conjunction  with  a  well  thought  out  open  systems 
approach,  will  contribute  greatly  to  DoD’s  effort  to  bring  the  latest  technology  and 
capability  to  the  warfighter  at  the  most  cost  effective  levels  and  be  able  to  sustain  such 
affordably.  However,  the  COTS  initiative  has  been  ongoing  for  over  10  years  and  the 
DoD  continues  to  struggle  with  COTS  supportability.  The  initiative  is  deeply  imbedded 
in  policy,  reviewing  criteria  and  procurement  methodologies  for  dealing  with  unforeseen 
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difficulties  in  implementing  COTS.  However,  given  the  long  development  cycles  and  the 
time-consuming  implementation  efforts  of  military  weapon  systems,  the  DoD  is  finally 
realizing  the  “cause  and  effect”  relationship  between  COTS  products  and  perturbations 
evident  in  fielded  systems.  One  only  needs  to  visit  the  Defense  Acquisition  Deskbook 
(DAD)  web  site  and  search  for  documents  that  address  COTS  implementation.  At  the 
time  of  this  writing,  there  were  over  230  listings  that  addressed  policy,  planning, 
designing,  fielding,  costing,  and  supporting  COTS.  DoD  5000.2-R  provides  guidance 
lessons  learned  for  PMs  in  dealing  with  COTS.  The  fact  of  the  matter  is  that  the  DoD 
acquisition  process  is  purposely  constructed  to  take  a  conservative,  thoughtful  approach 
to  implementing  change,  thereby  introducing  obstacles  to  the  time  elements  necessary  to 
keep  pace  with  the  commercial  environment.  The  most  important  point  to  understand 
here  is  the  disconnect  between  the  life  cycle  of  commercial  products  (1.5  to  5  years)  and 
the  typical  reaction  time  of  the  DoD  for  modernizing  fielded  weapon  systems. 
Remember  from  our  discussion  on  Perfonnance  Based  Logistics  that  system  support  is 
provided  in  whole  via  contracts  of  typically  5  years.  During  these  5  years  the  contractor 
or  supplier  is  responsible  for  ensuring  defined  levels  of  system  readiness  and  availability. 
During  this  period  sustainment  is  continuously  assessed.  Upon  notice  of  any 
obsolescence  issues,  the  PMO  has  to  decide  on  future  plans  for  support  or  redesign. 
Traditionally,  spares  are  bought  and  stored  based  on  a  forecasted  need  over  this  period  of 
time.  In  reaction  to  the  obsolescence  announcement,  the  PMO  enters  a  planning  period 
of  between  2  and  3  years.  Following  this  is  a  5  to  7  year  expectation  for  actual 
implementation.  So  we  are  looking  at  approximately  7  to  10  years  between  system 
upgrades  or  replacement  at  a  minimum.  But  now  consider  the  fact  that  these  systems  are 
expected  to  be  in  service  for  15  years  or  more  and  the  supportability  issues  become 
apparent  given  the  consistent  18-month  to  2-year  commercial  technology  life  expectancy. 
(See  Figure  3)  In  essence,  when  the  DoD  decides  to  use  COTS  products,  they  become 
obsolete  during  the  planning  phase.  Even  a  well-planned  approach  can  push  COTS 
technology  insertion  into  the  implementation  phase  only  to  become  obsolete  during  this 
period  as  well.  This  instability  to  systems’  design  baselines  is  a  major  issue  for 
maintaining  appropriate  readiness  and  availability.  Understanding  the  realities  associated 
with  implementing  and  supporting  COTS  products,  an  effort  must  be  made  to  deal  with 
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stabilizing  the  systems’  design  baselines  so  high  performance  in  terms  of  support  can  be 
achieved 

3.  COTS  Problem 

The  term  COTS,  Commercial-Off-The-Shelf,  refers  to  the  entire  range  of  products 
and  services  procured  by  the  DoD.  Nearly  every  weapon  system  and  their  basic  repair 
items  use  commercial  items  to  varying  degrees.  Today,  it  is  not  a  matter  of  all  or 
nothing,  but  how  much  of  the  system  is  COTS  based.  Figure  7  is  a  notional  interpretation 
of  COTS  as  is  defined  in  the  Federal  Acquisition  Regulation  (FAR)  Subpart  2.1,  Section 
2. 1.0.1  Definitions.  [27)  FAR] 
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Commercial 

Item 


(i) 

An  item  for  sale,  lease  or 
license  to  the  general  public 


(5) 

Services  procured  for  the 
support  of  (1),  (2),  (3)  & 
(4) 


(6) 

Services  offered  and  sold 
competitively  in  the 
commercial  marketplace  at 
catalog  prices 


(2) 

An  item  that  evolved  from 
(1)  that  will  be  available  in 
time 

1 

(3) 

Items  that  are  minor  or 
standard  modifications  of  (1) 
&(2) 


1 

(4) 

Any  combination  of  (1),  (2), 
"►  (3),  or  (5)  customarily  sold  to 
the  general  public 


1 

(7) 

Any  of  (1)  thru  (6)  that  have 
been  transferred  from 
another  of  a  contractor’s 
organizations 


(8) 

An  item  sold  competitively 
in  large  quantities  to  local 
and  state  governments 


Non- 

developmental 

Item 


(i) 

Any  previously  developed  item 
used  by  federal,  state,  local,  or 
allied  governments 


* 

(2) 

(1)  that  requires  only 
minor  modifications 


* 

(3) 

Integration  of  NDI  subsystems 
and  components 


Appendix  C  Figure  7:  Notional  depiction  of  FAR  COTS/NDI  Definition 

The  DoD  mandate  for  COTS  product  use  is  driven  by  two  important  situations. 
First,  the  fact  that  the  commercial  market  leads  the  DoD  in  latest  technology 
development;  therefore,  in  order  for  the  DoD  to  access  state-of-the-art  technology  they 
must  come  to  the  commercial  sector.  In  the  past  the  DoD  lead  the  way  in  research, 
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development  and  application  of  technology  for  military  weapon  systems.  Today  private 
industry  leads  the  DoD  in  these  areas.  Secondly,  the  present  industrial  base  is  very 
stable.  That  is  in  the  face  of  obsolescence,  DoD  suppliers  struggle  to  stay  in  business  due 
to  reduced  procurement  by  the  DoD.  The  larger  companies  have  sufficient  market  share 
to  remain  stable  through  these  periods  of  reduced  DoD  procurement.  Additionally,  they 
can  respond  to  a  surge  in  requirements  by  the  DoD. 

Given  the  widespread  use  of  COTS  products  in  military  weapon  and  support 
systems,  certain  challenges  are  being  faced  in  tenns  of  ensuring  long-term  supportability. 
The  challenges  stem  from  serious  obsolescence  issues  and  material  shortages.  The 
challenge,  in  essence,  is  to  provide  life  cycle  support  to  fielded  weapon  systems  that  use 
COTS  products.  Consider  for  a  moment  that  many  systems  will  have  life  cycles  that 
exceed  20  or  30  years,  and  one  can  easily  imagine  the  sustainment  nightmare  involved. 
The  slow  acquisition  process,  the  long  life  expectancies  and  traditional  support  methods 
are  not  consistent  with  commercial  business  practices.  In  fact,  there  is  little  incentive  for 
COTS  manufacturers  to  continue  to  produce  items  in  rather  small  quantities  just  for  the 
sake  of  ensuring  some  system  performance  baselines.  If  the  DoD  chose  not  to  use  COTS, 
there  would  be  little  impact  to  the  commercial  world.  However,  given  the  proliferation  of 
COTS  products  throughout  military  weapon  systems,  when  a  product  is  no  longer 
produced  the  impact  to  the  DoD  is  profound  and  severe.  Even  small  changes  to  a  product 
can  have  serious  repercussions  to  weapon  system  performance  and  design  baselines.  The 
fact  of  the  matter  is,  there  will  be  technology  changes  within  the  COTS  arena  and  they 
will  have  direct  impacts  on  military  weapon  systems,  both  fielded  and  under 
development.  Slight  changes  in  COTS  hardware  could  possibly  impact  interfaces  with 
other  equipment  or  systems  that  may  not  be  so  obvious.  Subtle  specification  changes  to 
COTS  hardware  (i.e.  timing,  execution...)  could  have  devastating  ripple  effects. 
Furthermore,  changes  to  hardware  could,  and  often  do,  require  changes  in  software  code 
in  the  larger  system.  A  change  in  code  translates  into  time  and  money.  Time  to  make  the 
necessary  changes,  test  the  changes,  and  deploy  the  changes  and  money  to  perform  these 
tasks.  This  is  not  hard  to  understand,  when  you  realize  that  many  systems  are  built 
around  software  (architectures  dictated  by  software).  Software  is  a  key  enabler  to 
achieving  open  systems  architecture,  as  software  is  assumed  easier  to  update  than 
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hardware.  Nevertheless,  slight  changes  in  software  do  have  a  cost  associated  with  it  and 
the  impacts  could  be  significant.  In  face  of  the  rapid  updates  to  software  in  the 
commercial  domain,  DoD  re-integration  efforts  can  be  difficult  and  expensive.  To  this 
end,  the  continue  implementation  of  COTS  products  in  the  development  of  military 
weapon  systems  will  lead  to  a  situation  where  these  systems  will  constantly  fall  prey  to 
technology  that  will  not  last  and  forever  changing. 

4.  Conclusion 

The  use  of  COTS  products  in  military  weapon  systems  is  a  reality.  DoD  5000.2 
and  the  Federal  Acquisition  Regulations  have  both  advocated  the  use  of  COTS  products 
due  to  the  potential  benefits  associated  with  leveraging  big  business  capabilities.  These 
capabilities  include  developing  state-of-the-art  technologies  and  delivering  them  in 
products  that  are  produced  in  quantities  that  reduce  cost.  To  this  end,  the  COTS 
manufacturers’  position  in  the  marketplace,  the  company  size  and  its  technology  edge 
impact  the  direction  and  update  cycles  of  technology  and  the  products  that  employ  them. 
Therefore,  COTS  products  hold  a  significant  place  in  weapon  system  development  and 
manufacturing  because  they  can  effectively  facilitate  the  quick  response  to  DoD  changing 
needs.  The  net  result  to  the  DoD  is  a  reduction  in  sustainment  costs  for  COTS  products 
as  well  as  improved  reliability  and  availability  of  the  weapon  system.  However,  since 
military  weapon  systems  are  typically  unique,  the  use  of  COTS  becomes  a  tricky  business 
in  terms  of  dictating  system  design  and  ultimately  life  cycle  support.  In  tenns  of 
software,  military  applications  tend  to  be  very  specific,  and  the  weapon  system  cannot 
tolerate  or  support  changes.  Compatibility  and  configuration-control  become  crucial 
elements  for  both  software  and  hardware.  Support  activities  are  pressured  to  maintain 
stabilized  baselines  in  order  to  keep  the  certification  of  the  system  verifiable.  These 
include  not  only  the  initial  integration  site  but  also  the  interoperability  of  fielded  systems 
subsequent  to  changes  (i.e.  installation  of  replacement  parts,  firmware,  software  or 
hardware  revisions,  etc...).  Needless  to  say  there  are  significant  risks  associated  with 
COTS  and  therefore  managing  these  risks  is  a  crucial  element  for  success.  For  weapon 
systems  that  do  use  COTS  products  some  of  the  more  identifiable  risks  are:  [28)  DoD] 

•  Engineering  changes,  increased  costs,  and  potential  schedule  delays  due  to 
poor  supportability  late  in  the  development  or  after  fielding  the  system. 
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•  Life  Cycle  Cost  (LCC)  estimates  for  COTS  product  usage  is  inaccurate  due  to 
poor  logistical  support  analysis. 

•  Poor  sustainability  due  to  not  considering  supportability  during  the  design 
phase. 

Understanding  these  risks  helps  us  to  better  define  where  the  problem  lies.  With 
the  problem  description  provided  above,  we  can  conclude  that  additional  supportability 
solution  alternatives  are  needed  to  address  the  shortcomings  of  the  present  COTS 
environment.  A  proactive  position  must  be  taken  to  include  these  alternatives  in  strategic 
supportability  planning  that  will  effectively  mitigate  the  risks  associated  with  COTS 
product  usage  in  military  weapon  systems. 

D.  LIMITATIONS  AND  CONSTRAINTS 

This  section  provides  some  further  contextual  infonnation  that  limits  or  constrains 
the  implementation  of  the  Sunset  Supply  Base  concept.  Specifically,  this  section  will 
address  DoD  policy,  reviewing  criteria,  and  methodologies  that  will  be  needed  to 
evaluate  the  business  case  results.  This  section  is  not  intended  to  provide  detailed 
information  on  the  specific  topics;  rather  a  general  understanding  is  expected  in  order  to 
realize  how  the  benefits  fit  within  the  limits  of  governmental  policy  and  regulation. 
Furthermore,  each  topic  will  be  discussed  in  tenns  of  COTS  products,  their  deployment 
in  military  weapon  systems,  and  their  relation  to  supportability  perfonnance. 

1.  DoDD  5000 

The  major  objective  of  DoDD  5000  [24)  DoD]  is  to  provide  a  model  to  the 
acquisition  community  for  reducing  cost  and  cycle  times  while  delivering  improved 
performance.  The  DoD  5000  process  is  a  carefully  constructed  methodical  approach  for 
rapidly  delivering  demonstrated  technology  to  the  warfighter.  This  purposely, 
conservative  approach  is  intended  to  optimize  the  acquisition  cycle  for  time-phased 
requirements  and  evolutionary  development.  Essentially,  the  DoD  acquisition  style  is 
moving  closer  to  commercial  practices.  This  movement  advocates  the  use  of  COTS 
products  for  achieving  rapid  technology  insertion  and  overall  constraining  life  cycle 
costs.  In  fact,  DoD  5000  recommends  that  cost  should  drive  design,  procurement  and 
support.  We  mention  DoDD  5000  here  not  as  an  attempt  to  educate  the  reader  on  the 
details  of  the  directive,  but  to  emphasis  the  boundaries  to  which  the  SSB  infrastructure 
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must  work  within.  Below  are  brief  descriptions  of  DoD  5000  acquisition  guidance  and 
general  expectation. 

Overview  -  The  Defense  Acquisition  system  exists  to  ensure  that  the  DoD’s 
investments  in  technologies  and  product  support  is  protected  throughout  the  entire  life 
cycle.  An  approach  must  be  taken  to  make  sure  that  demonstrated  technologies  could 
effectively  make  their  way  to  systems  that  enhance  warfighter  capabilities.  And 
additionally,  that  these  systems  can  be  supported  to  meet  readiness  and  availability 
demands. 

Policies  and  Principles  -  DoDD  5000.1  mandates  several  policies  and  principles 
for  managing  the  Defense  Acquisition  process.  In  broad  terms,  these  policies  and 
principles  cover  the  following  are: 

•  Rapid  and  effective  transitioning  of  science  and  technology  to  products  that 
enhance  warfighter  capabilities. 

•  Rapid  and  effective  transitioning  through  the  various  phases  of  the  life  cycle 
(Acquisition  =>  Deployment/Fielding) 

•  Integrated  and  effective  operational  support  throughout  the  entire  life  cycle. 
That  is  during  development,  installation  and  operation. 

•  Effective  program  management  throughout  the  entire  life  cycle. 

Operational  Support  -  The  PMOs  are  mandated  to  make  any  appropriate 
measures  for  integrating  acquisition  and  support  functions.  To  this  end,  they  are 
expected  to  focus  on  TOC  and  supportability  as  a  key  element  in  the  design  phase  of  the 
acquisition  cycle.  Supportability  is  to  be  used  as  a  perfonnance  indicator  essential  to  the 
systems  engineering  process.  DoDD  5000.1  essentially  advocates  a  transfonnation  in 
logistical  support  as  a  whole.  Specific  to  operational  support  the  PMOs  are  challenged  to 
provide  strategies  that  reduce  logistical  response  cycle  times  and  integrate  DoD  and 
commercial  expertise  all  in  an  effort  to  provide  the  optimal  customer  service  and  system 
readiness  levels.  To  realize  the  full  benefit  from  these  tasks,  PMs  are  directed  to  focus  on 
support  issues  as  early  as  possible  in  the  design  process.  The  end  result  is  the  delivery  of 
reliable  systems  that  can  be  cost-effectively  supported. 
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2. 


United  States  Code  10 


USC  Title  10  [29)  USHR]  provides  regulatory  elements  for  DoD  behavior. 
Within  Title  10  there  are  at  least  two  statues  that  specifically  address  product  support 
solutions  that  the  DoD  PMOs  must  comply  with. 

a.  Statue  2462 

(a)  In  General.  -  Except  as  otherwise  provided  by  law,  the 
Secretary  of  Defense  shall  procure  each  supply  or  service  necessary  for  or 
beneficial  to  the  accomplishment  of  the  authorized  functions  of  the  Department  of 
Defense  (other  than  functions  which  the  Secretary  of  Defense  determines  must  be 
performed  by  military  or  Government  personnel)  from  a  source  in  the  private 
sector  if  such  a  source  can  provide  such  supply  or  service  to  the  Department  at  a 
cost  that  is  lower  (after  including  any  cost  differential  required  by  law,  Executive 
order,  or  regulation)  than  the  cost  at  which  the  Department  can  provide  the  same 
supply  or  service,  (b)  Realistic  and  Fair  Cost  Comparisons.  -  For  the  purpose  of 
determining  whether  to  contract  with  a  source  in  the  private  sector  for  the 
performance  of  a  Department  of  Defense  function  on  the  basis  of  a  comparison  of 
the  costs  of  procuring  supplies  or  services  from  such  a  source  with  the  costs  of 
providing  the  same  supplies  or  services  by  the  Department  of  Defense,  the 
Secretary  of  Defense  shall  ensure  that  all  costs  considered  (including  the  costs  of 
quality  assurance,  technical  monitoring  of  the  performance  of  such  function, 
liability  insurance,  employee  retirement  and  disability  benefits,  and  all  other 
overhead  costs)  are  realistic  and  fair. 

b.  Statute-2464 

(a)  Necessity  for  Core  Logistics  Capabilities.  -  (1)  It  is  essential  for 
the  national  defense  that  the  Department  of  Defense  maintain  a  core  logistics 
capability  that  is  Government-owned  and  Government-operated  (including 
Government  personnel  and  Government-owned  and  Government-operated 
equipment  and  facilities)  to  ensure  a  ready  and  controlled  source  of  technical 
competence  and  resources  necessary  to  ensure  effective  and  timely  response  to  a 
mobilization,  national  defense  contingency  situations,  and  other  emergency 
requirements.  (2)  The  Secretary  of  Defense  shall  identify  the  core  logistics 
capabilities  described  in  paragraph  (1)  and  the  workload  required  to  maintain 
those  capabilities.  (3)  The  core  logistics  capabilities  identified  under  paragraphs 
(1)  and  (2)  shall  include  those  capabilities  that  are  necessary  to  maintain  and 
repair  the  weapon  systems  and  other  military  equipment  (including  mission- 
essential  weapon  systems  or  materiel  not  later  than  four  years  after  achieving 
initial  operational  capability,  but  excluding  systems  and  equipment  under  special 
access  programs,  nuclear  aircraft  carriers,  and  commercial  items  described  in 
paragraph  (5))  that  are  identified  by  the  Secretary,  in  consultation  with  the 
Chairman  of  the  Joint  Chiefs  of  Staff,  as  necessary  to  enable  the  armed  forces  to 
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fulfill  the  strategic  and  contingency  plans  prepared  by  the  Chairman  of  the  Joint 
Chiefs  of  Staff  under  section  153  (a)  of  this  title. 

c.  Federal  Acquisition  Regulations 

Federal  Acquisition  Regulations  [27)  FAR]  are  a  set  of  codified  and 
published  uniform  policies  and  procedures  for  acquisition  by  all  executive  agencies. 
With  respect  to  acquiring  COTS  products,  FAR  Subpart  12.2  addresses  the  Special 
Requirements  for  the  Acquisition  of  Commercial  Items.  There  are  13  sections  to  this 
subpart.  Each  section  addresses  a  specific  issue  for  the  acquisition  of  COTS  items.  The 
section  titles  are  listed  below  to  give  the  reader  a  sense  of  what  areas  this  regulation 
covers. 

•  Market  research  and  description  of  agency  need 

•  Procedures  for  solicitation,  evaluation,  and  award 

•  Solicitation/contract  form 

•  Offers 

•  Use  of  past  perfonnance 

•  Contract  Type 

•  Contract  quality  assurance 

•  Determination  of  price  reasonableness 

•  Contract  Financing 

•  Technical  Data 

•  Computer  Software 

•  Other  commercial  practices 

•  Cost  Accounting  Standards 

The  SSB  infrastructure  must  comply  with  the  regulations  set  forth  in  the 
Federal  Acquisition  Regulations  specifically  Subpart  12.2  and  its  policies  for  acquiring 
COTS  products.  Generally  speaking,  the  Federal  Acquisition  Regulation  in  terms  of 
COTS  implementation  has  guided  government  agencies  toward  a  more  commercial 
approach.  The  individual  government  agencies  should  try  to  achieve  a  balance  between 
public  and  private  resources  that  uniquely  fit  their  respective  needs.  Furthermore,  the 
PMOs  within  the  various  agencies  should  seek  appropriate  commercial  practices  for 
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acquisition  and  support  of  commercial  items.  The  contractual  arrangements  should  also 
reflect  this  migration  to  commercial  practices  to  the  point  that  government  interests  are 
preserved.  Appropriate  commercial  practices  should  be  actively  sought  out  that  proves  to 
be  satisfactory  to  both  commercial  and  government  entities  and  not  otherwise  precluded 
by  law  or  Executive  Order. 
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X.  ASSUMPTIONS  AND  METHODS 


This  section  describes  the  origin  and  use  of  the  data  and  the  methodologies 
employed  which  translates  the  data  into  final  results.  That  is  how  the  data  was  obtained 
and  the  methods  use  convert  this  data  to  information.  This  is  crucial  for  understanding 
the  BCA  results  and  leading  to  better  use  for  decision-making  purposes. 

A.  SCOPE  AND  BOUNDARIES 

Case  -  This  Business  Case  Analysis  is  performed  for  the  Navy’s  Ship  Self- 
Defense  System  MKI  (SSDS).  Below  is  a  brief  description  of  the  system.  [30)  Raytheon] 

Ship  Self-Defense  System  (SSDS) 

The  SSDS  is  a  combat  system  that  is  used  to  integrate  and  coordinate  all  of  the 
existing  sensors  and  weapon  systems  aboard  a  ship.  Its  purpose  is  to  provide  an 
automated  and  integrated  self-defense  capability  for  U.S.  Naval  surface  ships. 
The  system  provides  a  quick  response,  multi-target  engagement  capability 
against  close-in  threats.  The  goal  of  SSDS  is  to  coordinate  existing  shipboard 
resources  so  that  the  overall  ability  of  the  ship  to  defend  itself  is  enhanced  with 
respect  to  the  independent,  uncoordinated  operation  of  the  systems  currently 
installed.  To  do  this,  SSDS  produces  a  composite  track  picture  using  data  from 
the  various  sensors  on  the  ship. 

The  system  will  eventually  be  installed  aboard  most  classes  of  non-Aegis  ships. 

The  SSDS  is  managed  by  PMS461 

Source: 

http://www.ravtheon.com/products/ssds/ 

http://www.ihuapl.edu/programs/airdefense/ShipSD2.htm 

Time  -  The  period  of  analysis  is  between  fiscal  year  2003  and  2012.  The  data 
obtained  for  this  case  study  was  collected  in  FY  2002  and  applies  to  SSDS  program 
execution  beginning  in  FY2003. 
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Organization/Function  -  The  ultimate  goal  is  to  satisfy  warfighter  requirements; 
however,  there  are  many  stakeholders  within  the  SSB  infrastructure.  To  follow  are  brief 
descriptions  of  the  major  stakeholders 

The  End  User  -  Certainly  warfighter  must  be  considered  for  it  is  the  end  user  we 
depend  on  to  operate  our  weapon  systems  and  provide  the  expected  defense  as  defined  in 
our  national  strategic  policies. 

The  Program  Management  Offices  -  This  includes  the  initial  acquisition 
community  whose  purpose  is  the  acquisition  of  new  systems.  They  also  support  the  In- 
Service  Engineering  Activities  (ISEA)  that  must  continue  to  procure  parts  as  part  of  an 
alteration  kit  or  on-going  support  for  the  warfighter,  that  is  repair  and  replacements  of 
parts.  They  support  the  Integrated  Logistical  Support  (ILS)  functions,  which  must  plan 
the  long-term  support  of  fielded  equipment  and  must  support  equipment  between  changes 
to  the  equipment  baseline.  One  of  their  primary  responsibilities  is  budgetary  support  for 
personnel  who  must  plan  the  availability  of  products  that  extend  over  the  2-year  Program 
Objective  Memorandum  (POM)  cycle  and  the  3-5  year  implementation  cycle. 
Additionally  they  must  fund  Field  Activities  or  service  contractors  who  prepare  Cost, 
Health,  and  Risk  models,  which  quantify  the  availability  and  supportability  of  the  fielded 
systems. 

Interoperability  Support  Activities  -  These  activities  must  obtain  and  maintain  a 
stabilized  baseline  in  order  to  keep  the  certification  of  the  system  verifiable.  These 
support  activities  include  not  only  the  initial  integration  site  but  also  the  interoperability 
of  fielded  systems  subsequent  to  changes  (i.e.  installation  of  replacement  parts,  firmware, 
software  or  hardware  revisions,  etc.). 

Design  and  Development  Activities  -  These  activities  must  rely  on  commercial 
products  to  be  available  when  the  design  goes  into  production. 

Production/Manufacturing  Facilities  -  These  facilities  must  rely  on  the  source  of 
supply  in  producing  the  systems  they  were  contracted  for,  which  will  include  commercial 
products  that  contain  supportability  issues 
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B.  SSDS  COTS  WORKING  GROUP 


The  Ship  Self  Defense  System  (SSDS)  Commercial  Off  the  Shelf  (COTS)  and 
Non-Developmental  Item  (NDI)  Working  Group  (SCWG)  is  established  to  review, 
evaluate  and  recommend  resolution  for  COTS  and  NDI  obsolete  parts  design, 
technology,  application,  availability/procurement,  and  process  issues  in  a  timely  and 
efficient  manner.  The  SCWG  assists  the  Program  Manager  (PM)  with  identification  of 
COTS,  obsolete  parts,  and  technology  requirements,  clarification  of  contractual  concerns, 
and  compliance  with  acquisition  reform  initiatives  involving  COTS.  The  SCWG  Charter 
is  provided  as  Enclosure  6. 

C.  COST  MODEL 

The  cost  modeling  was  accomplished  through  the  use  of  two  unique  models 
combined  into  one.  NSWC  Crane  provided  a  traditional  Sustainment  Engineering  cost 
model  (here  after  referred  to  as  the  resource  model),  which  focused  on  upper  level 
assembly  procurement  costs  and  associated  resource  requirement  costs.  NSWC  Corona 
developed  a  procurement  cost  model  (here  after  referred  to  as  the  procurement  model) 
reflecting  granularity  down  to  the  component  piece  part  level  (i.e.  below  the  assembly 
level)  to  identify  obsolescence  issues  and  their  associated  cost.  The  resource  model 
provided  a  well-established  structure  and  process  to  perfonn  simulation  and  evaluation 
on  “What  if’  scenarios  using  various  support  methodologies.  However,  the  resource 
model  lacked  the  insight  to  component  piece  part  obsolescence  and  the  capability  to 
quantify  their  cost  impacts  or  a  resolution  method  addressing  this  low  level.  Used 
independently  the  resource  model  addresses  obsolescence  at  the  assembly  level  whereby 
the  potential  resolutions  were  limited  to  assembly  level  mitigation  resolutions.  The 
procurement  model  provided  initial  costs  of  component  piece  part  obsolescence  and 
projected  future  year  costs  at  this  low  level.  The  procurement  model  is  intricately  tied  to 
the  SSB  system  for  generation  of  the  necessary  data  and  as  part  of  the  SSB  system  risk 
mitigation  resolution  methods  are  available  for  component  piece  part  obsolescence.  This 
visibility  into  the  low  level  obsolescence  and  associated  cost  provides  new  knowledge 
and  resolution  methods  previously  unavailable.  Used  independently  the  procurement 
model  can  show  impacts  on  procurement  costs  given  various  scenarios,  however  lacks 
the  overarching  view  to  identify  impacts  to  resource  costs.  Combining  the  two  models 
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allows  the  user  to  leverage  the  structure  and  simulation  of  both  the  procurement  costs  and 
the  associated  resources  available  through  the  resource  model  while  having  the  visibility 
of  low  level  obsolescence  costs  combined  with  alternative  resolution  methods.  The 
models  were  combined  by  first  running  the  procurement  model  using  a  specific  scenario 
then  using  its’  output  as  an  input  to  the  resource  model  subsection  of  the  Work 
Breakdown  Structure  (WBS)  labeled  -  Procurement.  Additionally,  cost  figures  were 
developed  to  reflect  the  cost  to  implement  the  SSB  system,  these  in-turn  were  identified 
in  the  WBS  as  SSB  resource  costs. 

1.  The  Resource  Model  (Enclosure  (30)) 

Naval  Surface  Warfare  Center  (NSWC)  Crane  Division  has  developed  a 
Technology  Planning  and  Management  Cost  Model,  which  accurately  and  efficiently 
calculates  the  estimated  cost  of  most  support  strategies  required  by  Navy  PMOs.  Their 
focus  is  on  COTS  products  in  military  applications.  They  act  as  a  consultant  to  PMs  and 
work  in  conjunction  with  both  government  and  commercial  system  designers  and 
integrators,  in  the  life  cycle  management  of  systems  that  incorporate  COTS  products. 
NSWC  Crane  provides  technology  assessments  that  help  PMs  with  commercial 
technology  management.  The  mission  of  NSWC  Crane  is  “...to  provide  low  cost, 
quality,  and  responsive  acquisition,  engineering,  logistics,  and  maintenance  for  the  Fleet's 
weapon  and  electronic  systems,  ordnance,  and  associated  equipment  and  components.” 
They  accomplish  this  through  “...partnerships  with  industry,  academia,  and  government 
activities.”  [31)  NSWC/Crane] 

The  model  was  designed  based  on  the  cost  breakdown  structure  (CBS)  required 
for  proper  preparation  and  submittal  of  engineering  change  under  DOD-STD-480, 
whereby  it  reflects  the  resources  and  requirements  for  a  given  alternative.  Estimating 
methodology  for  each  category  of  costs  was  developed  in  accordance  with  accepted  and 
anticipated  practices  within  a  specific  program  community  for  a  technology  refresh 
engineering  change,  from  proposal  submittal  and  approval  to  installation  of  the  change. 
Both  these  costs  and  activity  categories  were  combined  into  a  high-level  breakdown 
structure  and  are  submitted  with  a  total  work  breakdown  structure  (WBS)  containing  over 
120  categories.  The  high-level  WBS  is  as  follows: 

•  Configuration  Management 
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•  Hardware/Software  Engineering 

•  Testing  and  Documentation 

•  Procurement 

•  ILS  Planning  and  Management 

•  Installation 

In  order  to  design  a  cost  model  that  accurately  reflects  the  cost  of  a  supportability 
option,  the  cost  analyst  had  to  understand  the  processes  (and  associated  costs)  that  are  a 
part  of  each  of  the  areas  listed  above.  The  Subject  Matter  Experts  (SMEs)  on  the 
technology  assessment  team  for  the  program  played  a  key  role  in  assisting  the  analyst  to 
capture  those  processes.  The  NSWC  Crane  cost  model  is  designed  with  variables  that 
can  be  used  to  describe  changes  made  to  the  system  under  a  chosen  supportability  option. 

Certain  decisions  made  in  the  various  support  scenarios  were  guided  by  input 
from  NSWC  Crane  Division.  They  prepare  a  COTS  Availability  Risk  Assessment 
(CARA)  that  provides  in-depth  knowledge  of  the  availability  of  each  COTS  item  used  in 
the  combat/weapon  system.  Some  of  the  basic  availability  questions  that  it  answers  are: 

•  Is  the  manufacturer  still  making  it? 

•  If  not,  can  we  still  buy  it? 

•  Can  the  manufacturer  still  repair  it? 

•  Is  there  an  after-market  supplier  for  the  product? 

•  Where  does  this  product  fit  in  the  company’s  product  roadmap? 

•  Is  the  technology  (or  technologies)  used  in  the  design  of  the  product  state-  of- 
the-art  and  widely  used  in  industry? 

NAVSEA  Crane  Division  provided  the  data  presented  in  Enclosure  (30).  The 
cost  data  found  in  this  enclosure  was  based  on  cost  models  generated  and  used  by  NSWC 
Crane  in  support  of  the  decision  making  process  at  the  program  office  level  for  COTS 
applications.  The  information  contained  in  this  spreadsheet  used  COTS  specific  data  for 
populating  the  various  resource  fields.  This  data  includes  item  failure  rate,  purchasing 
price  and  repair  costs.  Also,  any  program-specific  infonnation  that  impacts  the  support 
decision  is  considered  and  documented  in  the  CARA,  such  as  government  sources  of 
supply,  system  procurement  and  installation  schedules,  and  quantities  of  items  used  in 
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system  design.  The  actual  algorithms  are  not  accessible  within  this  file  but  are  consistent 
across  all  applications  of  its  use. 

The  resource  model  is  designed  to  offer  several  methods  of  supporting  a  particular 
component  over  its  life  cycle.  These  different  support  alternatives  are  implemented  at  the 
assembly  level  in  a  typical  application  however  another  alternative  -  After  Market 
(Sunset  Supply  Base)  -  has  been  added  which  provides  low  level  visibility  and  resolution 
of  obsolescence.  Below  are  descriptions  of  the  typical  methods  and  the  SSB  alternative. 

Bridge  Buys  -  A  bridge  buy,  referred  to  as  a  Life  of  Type  Buy  (LTB)  in  this  BCA, 
is  a  short-term  buy  solution  to  an  availability  problem.  Items  are  purchased  to  bridge  the 
time  from  some  point  before  product  obsolescence  to  a  known  point  in  time  when  a 
refresh/upgrade  is  planned.  Often  a  bridge  buy  is  performed  while  the  logistics  of  the 
agreed-upon  long-term  solution  become  finalized  for  execution.  In  essence,  a  bridge  buy 
should  provide  the  customer  some  time  by  solving  the  immediate  availability  problem  for 
a  period  of  six  months  to  three  years.  Bridge  buys  may  be  desired  for  many  reasons:  1) 
inability  to  accurately  assess  and  predict  the  lifetime  demand,  2)  inabilities  to  acquire 
funding  for  a  Life-of-Type  (3  to  10  year)  buy,  and  3)  a  redesign  is  the  desired  long-term 
solution,  but  budget  constraints  may  delay  the  effort  for  a  finite  term.  Guidelines  for 
making  the  repair/replace  decision  should  be  as  follows: 

•  If  considering  a  bridge  buy  solution,  high  price  items  should  be 

investigated  for  repair  as  opposed  to  a  bridge  buy 

•  If  considering  a  repair  concept,  bridge  buys  should  be  estimated  when  the 

cost  to  repair  is  equal  to  or  greater  than  the  cost  to  replace. 

Spares  Utilization  -  Spares  utilization  may  be  an  option  to  support  the  equipment 
until  a  refresh/redesign  is  planned.  Typically  such  spares  come  from  supplies  maintained 
from  the  prime  contractor,  from  the  In-Service  Support  Activity,  or  from 
decommissioned  assets  tracked  by  Naval  Inventory  Control  Point  (NAVICP). 

Maintenance  Contracts  -  Maintenance  contracts  with  vendors  are  utilized  to  deal 
with  obsolescence  instead  of  bridge  buying  an  item.  This  method  can  be  used  to  support 
products  until  a  technology  refresh  and/or  end  of  system  life.  This  concept  allows  the 
delay  of  a  technology  refresh  due  to  the  repair  capability  after  product  obsolescence.  In 
most  cases,  it  allows  the  Program  Manager  to  lower  his  support  cost  due  to  the  cost  of 
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repair  being  less  than  the  replacement  costs.  This  philosophy  contains  some  inherent  risk 
associated  with  vendor's  capability  to  repair  and  the  repair  support  period  the  vendor  is 
willing  to  sign-up  for. 

COTS/NDI  replacement  -  Two  approaches  can  be  taken  for  COTS/NDI 
replacement.  For  a  minor  impact  solution  approach,  it  is  possible  that  the  problem 
product  is  replaced  by  a  newer  revision  of  the  same  product,  an  entirely  new  product  of 
the  same  family.  The  major  impact  solution  approach  consists  of  a  technology  upgrade 
change  from  the  same  vendor  -  or  an  entirely  new  product  and  vendor.  Low  complexity 
and  cost  products  will  usually  fall  into  the  first  solution  approach  category  (newer  version 
of  the  same  product).  This  type  of  replacement  produces  a  minimum  impact  on  the 
system.  Moderate  complexity  and  cost  products  can  cause  a  minimal  impact  and  need  to 
be  investigated  on  a  case  per  case  basis.  Both  A  and  B  types  require  an  Engineering 
Change  Proposal  (ECP);  however,  the  additional  costs  incurred  by  the  ECP  process  are 
not  taken  into  account.  High  cost  and  complexity  products  will  usually  cause  a  major 
impact,  requiring  a  class  I  ECP  with  associated  processes,  approvals,  and  costs.  The 
program  has  the  associated  risk  of  impacting  the  interoperability  of  the  system  using 
either  solution. 

After  Market  (Sunset  Supply  Base)  -The  after  market  approach,  referred  to  in  this 
paper  as  the  Sunset  Supply  Base  (SSB),  extends  the  supportability  of  COTS  products  and 
items  of  material  shortage  predicated  on  the  needs  of  the  Navy  programs.  The  SSB  is  an 
extension  of  product  availability,  beyond  the  Original  Equipment  Manufacturer  (OEM) 
assigned  date  to  drop  the  products  as  obsolete  items,  which  provides  stability  to  the 
system  baseline  configuration  over  a  defined  period  of  time  between  scheduled  Technical 
Refresh/  Insertion  points. 

2.  Procurement  Cost  Matrices 

The  Procurement  Cost  Matrices  in  this  BCA  is  actually  the  combined  product  of 
two  enclosures  that  are  identified  and  described  below  at  a  high  level: 

•  Enclosure  (28)  -  SSDS  Assembly  Master  &  Cost  Matrices 

•  Enclosure  (29)  -  SSB  Planning  Excel  Workbook  &  Data  Item  Description 
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The  area  of  measurement  and  assessments  is  the  Capstone  of  the  entire  SSB 
system’s  implementation  effort.  It  brings  together  all  the  information  and  data  collected 
and  provides  functionality  previously  unattainable  without  the  SSB  system  -  Systems 
Engineering  approach.  The  Capstone  assessment  tool  is  illustrated  in  Enclosure  (28)  - 
SSDS  Assembly  Master  &  Cost  Matrices.  Every  tool,  method,  and  process  developed  to 
implement  the  SSB  system  is  either  directly  or  indirectly  responsible  for  the  numbers 
evident  in  the  matrices.  Enclosure  (29)  -  SSB  Planning  Excel  Workbook  &  Data  Item 
Description  -  provides  detailed  explanations  for  the  descriptions  of  each  cell  along  with 
the  mathematical  relationships  and  constraints  implemented  within  the  worksheet. 
Enclosure  (29a)  -  SSB  Program  Workbook  Template  -  provides  a  ready  to  use  template 
with  embedded  algorithms  for  immediate  application  using  data  generated  from  another 
new  program.  Enclosure  (29b)  -  Fonnula  Helper  -  identifies  in  succinct  form  the 
equations/relationships  embedded  within  the  SSB  Program  Workbook  Template  so  that  at 
any  time  the  user  can  check  the  integrity  of  the  embedded  algorithms. 

This  enclosure  (28)  provides  the  procurement  cost  data  for  supporting  COTS 
products  on  the  SSDS  program  under  different  scenarios.  The  infonnation  is  presented  in 
Microsoft  Excel@  spreadsheet  format.  The  infonnation  has  been  created  to  support  the 
analysis  of  the  year-to-year  cost  and  corresponding  total  cost  of  supportability  options  for 
assemblies  in  a  system.  The  data  used  corresponds  to  the  SSDS  MK  I.  Given  the 
complexities  of  the  algorithms  and  the  interrelationships  designed  into  the  workbook, 
explanation  of  these  relationships  and  manipulation  of  the  data  is  best  accomplished 
through  reading  Enclosure  (29)  in  its’  entirety.  A  brief  description  identified  below 
illustrates  the  primary  information  and  data  considered  in  developing  any  given  solution 
set. 

The  Excel  Workbook 

The  Excel  Workbook  contains  several  spreadsheets  as  listed  below: 

Global  Information: 

This  data  relates  to  all  parts  in  the  system(s)  and  is  used  by  the  calculations  of  the 
number  of  spare  parts  required  and  as  stopping  criteria  for  the  cost  matrices.  The  global 
information  is: 
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Mission  Years:  The  total  years  of  the  Mission  life. 

Hours  per  year:  The  MTBF  is  given  in  hours  so  this  is  simply  the  total  number  of 
hours  in  a  year. 

Percent  utilization:  The  expected  percent  of  time  that  the  system  is  expected  to  be 
operational. 

Total  Mission  Hours:  Mission  Years  *  Hours  per  Year  *  Pet  Utilization 

Number  of  MK I  Systems,  MK II  Systems:  This  spreadsheet  has  been  seeded  with 
data  that  relates  to  the  SSDS  MK  I  &  MK  II  Systems.  These  values  represent  the 
number  of  fielded  systems  that  the  data  is  being  generated  to  support. 

Program  Year  Names  and  corresponding  integer  year  into  Mission:  These  values 
are  used  to  display  the  chosen  start  year  and  subsequent  years  in  series  on  the 
Cost  Matrix  spreadsheets. 

SSDS  Master  Assembly  List: 

Each  record  in  this  worksheet  is  for  a  particular  assembly  in  the  SSDS  system. 
The  data  is  collected  from  the  manufacturers  and  Navy  database  information  and 
generated  based  on  the  global  information  and  statistical  functions  based  on  an 
Exponential  Life  Testing  model.  For  an  explanation  of  this  model  see  the  section  at  the 
end  of  this  section.  The  Assembly  Master  information  is: 

1)  Individual  Assembly  Information: 

Unique  ID:  This  is  used  for  ease  of  reference  to  an  assembly  and  also  for  sorting 
after  the  data  has  been  imported  to  a  system  specific  worksheet  (i.e.  MK  I 
Subset.) 

Company:  The  name  of  the  manufacturer  or  supplier  of  the  assembly. 

#  Parts  for  vendor:  This  is  used  for  a  subtotal  calculation  to  logically  separate  the 
assemblies  by  vendor  and  show  the  number  of  assemblies  this  supplier  is 
providing. 

Supplier  Part  #s:  As  given  by  the  manufacturer. 

2)  Pricing  Information: 

Price  per  part:  The  price  for  each  assembly  as  given  by  the  manufacturer. 

Adjusted  price  per  part:  This  value  is  the  price  per  part  shown  above  plus  5%. 
This  percentage  is  in  payment  for  holding,  storing  and  maintaining  stock 
levels  of  ‘Red  Parts’  (see  below)  for  the  Sunset  Supply  Base  (SSB) 
supportability  option  calculations. 

Non-reoccurring  Engineering  Cost  (NRE):  This  value  is  provided  by  the 
manufacturer  and  represents  the  cost  to  set  up  the  infrastructure  associated 
with  implementing  the  SSB  for  this  assembly. 
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Red  Parts  Price:  If  the  SSB  supportability  option  is  used,  this  cost  reflects  the 
price  quoted  for  the  parts  that  are  the  obsolete  parts  purchased  and  stored 
while  still  available  from  the  manufacturer  or  in  the  gray  market. 

Non  SSB  Support  Cost:  At  present  this  column  is  not  being  used. 

3)  MTBF  Infonnation: 

Mean  Time  between  Failure  (MTBF)  given  in  hours. 

MTBF:  MTBF  is  provided  from  the  Original  Equipment  Manufacturer  (OEM) 
either  calculated  or  demonstrated. 

MRDB  MTBF:  Represents  the  actual  MTBF  exhibited  in  the  equipment  fielded 
in  Navy  applications. 

Adjusted  MTBF:  The  most  appropriate  MTBF  from  the  two  listed  above  or 
additional  adjustment  due  to  performance  experience.  This  value  is  used 
for  the  calculation  of  the  failure  rate  used  in  the  Exponential  Life  Testing 
Model  yielding  the  required  Number  of  Parts  to  Purchase  in  Advance. 

4)  Important  Dates: 

Used  to  determine  the  number  of  parts  to  buy  in  any  given  year  is  dependent  on 
the  availability  of  the  part  and  the  service  time  for  the  part. 

EOP:  End  of  Production.  The  last  date  that  the  assembly  can  be  procured. 

Years  remaining  to  Buy:  Based  on  the  EOP  date.  The  corresponding  number  of 
years  remaining  to  buy  the  part.  Used  to  detennine  purchase  schedule. 

EOS:  End  of  Service.  The  last  date  that  the  assembly  can  be  serviced. 

5)  System  Part  Infonnation: 

Enumerated  value:  If  the  assemblies  listed  are  used  on  one  or  both  systems,  a  key 
value  can  be  entered  here.  These  values  are  used  to  extract  data  for  an 
individual  system  by  sorting. 

#  Parts  on  each  System  (1):  Each  Mark  I  System  has  this  quantity  of  parts 

installed. 

Total  parts  for  all  Systems  (1):  Uses  the  total  number  of  MK  I  Systems  from  the 
Global  Infonnation  worksheet 

#  Parts  on  each  System  (2): 

Total  parts  for  all  Systems  (2): 

#  Parts  for  all  Systems:  The  combined  total  number  of  installed  assemblies  for  all 

systems. 

6)  SSB  Information 

Support  Method:  Currently  there  are  3  supportability  options  implemented: 

SSB:  Use  the  SSB  model  for  product  support,  purchase  schedule  and  cost  data. 
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LTB:  Life  Time  Buy.  Dependent  on  the  ‘Years  remaining  to  Buy’  in  the 
‘Important  Dates’  section.  The  quantity  of  parts  calculated  for  purchase  in 
any  given  year  may  vary  based  on  the  ability  to  purchase.  Also,  the  entire 
assembly  is  purchased.  It  is  implied  that  this  option  is  for  parts  that  are 
not  expected  to  have  any  obsolescence  issues. 

OTHER:  Costs  estimates  for  alternative  “OTHER”  are  based  on  engineering 
judgment  in  the  cases  involving  proposed  ECPs  were  prepared  by  NSWC 
Port  Hueneme,  the  In-Service  Engineering  Activity  (ISEA)  for  the  SSDS. 
In  some  cases,  estimates  were  provided  by  NSWC  Crane  based  on 
reasonable  redesign  estimates  extracted  from  their  cost-modeling  tool. 

X 

Confidence  Interval:  The  Upper  Confidence  Limit,  ■" ,  allows  the  calculation  of 
the  MINIMUM  MTBF  that  would  occur  in  the  given  Probability  Confidence  Interval. 
Using  this  value,  we  can  calculate  the  MAXIMUM  number  of  parts  that  would  be  needed 
to  remain  within  this  confidence  interval.  The  value  of  F  (below)  used  is  the  Expected 
Mean  Failure  calculated  with  the  given  MTBF. 

Expected  Mean  Failures  (F):  Based  on  the  MTBF  and  the  Global  Information  of 
Mission  Time  Hours.  Calculates  the  Expected  Mean  number  of  assemblies  that  will  fail 
over  the  Mission  life  cycle.  Where: 

X  =  Failure  rate  over  Time  =  reciprocal  of  MTBF 

n  =  Number  of  Parts  for  all  systems 

T  =  Total  Hours  of  Mission  Time 

F  =  Expected  Mean  Failures  =  k*n*T 

Number  of  Parts  to  Purchase  in  Advance:  From  the  information  for  Exponential 
Life  Testing,  the  number  of  parts  to  purchase  in  advance  represents  the  maximum  amount 
that  may  be  needed  based  on  the  %  confidence  interval. 

Average  Parts  Per  Year:  Simply  divides  the  total  number  of  parts  calculated  for 
the  corresponding  confidence  interval  by  the  Mission  Time  in  years.  Used  to  determine 
the  minimum  number  of  parts  to  purchase  in  the  earlier  years  of  the  Mission. 

System  (1)  Subset: 

This  worksheet  is  created  by  taking  a  subset  of  the  Master  Assembly  worksheet 
and  using  the  ‘Past  Link’  function  available  in  Excel.  This  allows  for  the  values  to  reflect 
exactly  the  corresponding  values  from  the  Master. 
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System  (1)  Cost  Matrix  (1): 

This  worksheet  contains  the  individual  formulas  to  calculate  the  number  of  parts 
to  buy  in  a  given  Program  Year  and  the  associated  cost.  Each  Fiscal  Year  has  six 
columns,  two,  which  are  visible,  and  the  other  four,  which  are  Grouped  and  Closed.  The 
first  two  columns  are  for  the  supportability  option  of  SSB.  The  second  two  columns  are 
for  the  supportability  option  of  LTB.  The  supportability  option  of  OTHER  is  imported 
from  the  final  worksheet,  which  has  rows  for  each  assembly  and  will  contain  assembly 
specific  information.  This  infonnation  was  provided  by  the  ISEA  and  the  information 
corresponded  to  the  sum  total  of  parts  purchased  and  resources  consumed. 

Use  of  the  Exponential  Life  Testing  Model  gives: 

F  =  Failures  occurring  in  the  system  over  the  accumulated  time  TO 

F  is  P  (k  TO),  the  probability  of  occurrence  is  a  Poisson  Process 

i  =  MLE  =  MVUE  =  — 

T 
1  o 

Where: 

MLE  is  the  Maximum  Likelihood  Estimator  and 

MVUE  is  the  Minimum  Variance  Unbiased  Estimator 

_  Za,2(l+F) 

Jt  fov/ 1  ^  27^ 

The  Upper  Confidence  Limit  of  mean  failure  rate:  is:  0 

Where: 

a  =  1  -  Probability,  i.e.  99%  Probability  gives  a  =  0.01 

Reliability  R  (t)  =  P  (TO  >  t)  =  e-kt 

Failure  Density  function  f  (t,  k)  =  k  e-kt 

The  Upper  Confidence  Limit,  fl ,  allows  the  calculation  of  the  MINIMUM  MTBF 
that  would  occur  in  the  given  Probability  Confidence  Interval.  Using  this  value,  we  can 
calculate  the  MAXIMUM  number  of  parts  that  would  be  needed  to  remain  within  this 
confidence  interval.  The  value  of  F  used  is  the  Expected  Mean  Failure  calculated  with 
the  given  MTBF. 
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B.  SUPPORT  METHOD  SCENARIOS 


In  this  case  study  there  are  three  main  practical  scenarios  that  could  be 
implemented  to  support  the  SSDS  program  over  the  defined  ten-year  period  and  each  are 
described  in  a  separate  worksheet  labeled  with  the  names  identified  below. 

1.  LTB(l) 

This  scenario  is  the  likely  track  for  COTS  product  support  without  any  assistance 
from  the  SSB  infrastructure.  The  costs  for  this  scenario  are  the  estimated  financial 
impacts  that  the  SSDS  Program  Office  must  plan  for.  The  support  methods  are  broken 
down  into  two  methods:  1)  Life  Time  Buy  (LTB),  which  is  a  bridge  buy  as  described 
previously,  and  2)  OTHER.  OTHER  refers  to  redesign,  spares  utilization,  reclamation 
from  other  fleet  assets  or  maintenance  contracts. 

2.  SSB(l) 

This  scenario  is  the  most  appropriate  implementation  of  the  SSB  infrastructure  as 
agreed  upon  by  the  SSDS  COTS  Working  Group  (SCWG).  Three  main  support  methods 
are  employed:  1)  SSB,  2)  LTB  and  3)  OTHER  as  described  above. 

3.  SSB  Optimized 

This  scenario  implements  the  SSB  method  wherever  possible.  Certain  support 
decisions  were  made  for  specific  COTS  products  prior  to  the  availability  of  the  SSB 
infrastructure.  Some  COTS  products  have  already  been  slated  for  redesign  or 
reclamation  efforts. 

In  addition  to  these  scenarios,  three  additional  scenarios  are  identified.  These 
represent  the  “What-If  ’  scenarios. 

•  LTB  Only  -  This  scenario  uses  the  LTB  support  method  for  all  COTS 
products. 

•  SSB  Only  -  This  scenario  uses  the  SSM  support  method  for  all  COTS 
products. 

•  Complete  Tech  Refresh  -  In  this  scenario  every  COTS  product  within  the 
SSDS  is  planned  for  redesign  or  technology  refresh  over  the  next  ten-year 
period. 
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C.  CURRENT  STATE  ASSESSMENT 

Military  acquisition  is  characterized  by  high  development  costs  and  very  long 
development  cycles;  therefore  military  procurements  are  forced  to  project  future  needs 
and  purchase  as  many  products  or  components  as  they  think  they  will  need.  Furthermore, 
in  light  of  unique  military  applications,  the  lengthy  life  cycles  and  the  5  to  7  year 
technology  refresh  rate,  the  DoD  realizes  that  they  presently  have  no  control  over  product 
evolution,  and  therefore  must  compensate  by  staying  aware  of  pending  changes.  This  is 
critical  if  the  military  is  to  expect  any  appreciable  success  in  support  of  their  weapon 
systems.  Operational  and  maintainability  support  is  expected  over  the  entire  life  cycle  of 
the  system.  This  includes  support  for  design  and  development  efforts  as  well.  As 
mentioned  previously,  DoD  design  and  development  cycles  spanning  10  to  15  years,  are 
expensive  and  often  deploy  out  of  date  equipment.  These  design  and  development 
activities  must  rely  on  commercial  products  to  be  available  when  the  design  goes  into 
production.  Furthennore,  production  and  manufacturing  facilities  must  rely  on  the  source 
of  supply  in  producing  the  systems  they  were  contracted  for,  which  will  include 
commercial  products  that  contain  their  own  supportability  issues. 

The  impacts  of  ineffectiveness  to  support  our  weapon  systems  throughout  their 
life  cycle  will  be  realized  in  military  readiness  and  capability.  When  we  consider  the 
huge  investments  that  DoD  makes  in  getting  technology  to  the  warfighter  and  training 
our  warfighter,  support  of  our  weapon  systems  should  not  be  the  weak  link  in 
maintaining  high  levels  of  combat  readiness  and  personnel  safety.  This  weak  link  might 
be  the  result  of  the  ever-increasing  pressure  to  reduce  costs.  Very  often  we  hear  of  cost 
as  the  independent  variable  in  design  and  development  efforts  and  that  Total  Ownership 
Costs  (TOC)  should  be  factored  into  the  design  process.  To  do  this  the  design  activities 
must  maintain  a  holistic  perspective  of  the  system  to  include  life  cycle  support  of 
technologies  that  have  been  selected  for  insertion  into  their  weapon  systems.  With  the 
challenge  of  reducing  costs  and  effectively  supporting  the  warfighter,  today's  systems 
architects  for  DoD  systems  must  understand  what  drives  cost  in  order  to  carefully 
consider  alternatives  for  life  cycle  support. 
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The  cost  associated  with  supporting  weapon  systems  throughout  their  life  cycle  is 
perhaps  most  sensitive  to  the  availability  of  components  that  are  needed  to  maintain 
stability  in  the  operational  context.  As  legacy  systems  age,  their  associated  support  and 
maintenance  costs  rise  dramatically  due  to  obsolescence,  reliability  and  supportability 
problems  while  at  the  same  time  the  performance  of  the  system  decreases.  As  original 
equipment  manufacturers  synchronize  their  product  lines  with  technology,  products 
presently  deployed  in  DoD  weapon  systems,  as  well  as  products  intended  for  use  in 
developmental  systems,  will  be  affected.  Alternate  components  or  parts  will  need  to  be 
considered  for  acceptance  or  rejection.  There  will  be  material  shortages  occurring 
because  of  the  social,  economic,  and  political  environments.  In  either  case  there  will  be 
costs  associated  with  these  decisions  and  cost  must  be  managed  effectively.  If  the 
alternate  part  is  accepted,  an  engineering  change  proposal  will  need  to  be  initiated.  There 
is  cost  associated  with  preparation,  coordination,  scheduling  and  testing  of  the  alternate 
part.  If  the  alternate  part  is  unacceptable,  large  product  buys  will  be  needed  to  ensure 
operational  integrity  and  support  of  the  system  over  its  life  cycle.  There  is  cost  with 
developing  a  new  source  of  supply.  In  these  cases  there  are  issues  of  where  to  buy,  how 
much  to  buy,  where  to  stock  them,  and  how  to  manage  the  costs  and  logistical  support  to 
meet  the  needs  of  the  customer. 

Recently,  the  Navy  has  gone  to  a  concept  called  Performance  Based  Logistics 
(PBL)  in  an  effort  to  provide  the  fleet  with  increased  reliability  and  availability  at  the 
same  or  reduced  cost.  The  Naval  Inventory  Control  Point  (NAVICP)  ensures  that  PBL 
arrangements  meet  the  requirements  of  the  fleet.  In  essence,  under  a  PBL  arrangement,  a 
single  supplier  provides  material  and  support  to  the  fleet  consistent  with  the  Navy’s 
requirements.  This  contract  is  executed  without  the  intervention  of,  or  need  for 
government  inventory  managers,  storage,  material  handling,  and  transportation  systems. 
The  goal  is  to  provide  increased  availability,  reliability,  technology  insertion,  and 
obsolescence  management  at  a  lower  cost  to  the  Navy.  They  use  a  Business  Case 
Analysis  (BCA)  approach  to  determine  a  ‘best  value’  approach  given  reduced  funding. 
For  each  PBL  initiative,  NAVICP  will  conduct  a  BCA.  This  BCA  is  designed  to  quantify 
any  cost  benefits  the  Navy  will  realize  through  the  initiation  of  a  PBL  contract.  The  BCA 
process  involves  detennining  the  Navy's  current  cost  of  doing  business.  This  "without 
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PBL"  cost  is  then  compared  to  the  cost  to  the  Navy  if  they  execute  a  PBL  arrangement. 
This  "with  PBL"  cost  includes  both  the  PBL  supplier's  costs  as  well  as  the  residual  costs 
the  Navy  will  retain  even  under  a  PBL  arrangement.  All  savings  must  be  quantifiable 
and  traceable. 

Under  this  arrangement,  the  supplier  is  contractually  bounded  to  deliver  the 
prescribed  capabilities  a  defined  period  of  time.  Performance  of  the  supplier  is 
continually  assessed  against  the  terms  of  the  contract.  Consider  a  typical  contract  period 
of  five  years  and  assume  this  is  the  first  contract  this  particular  supplier  has  received.  At 
some  point  in  the  five-year  period,  a  COTS  obsolescence  issue  may  arise.  If  this  occurs 
even  within  the  first  year,  recall  we  expect  a  2-3  year  planning  period  to  solve  the 
obsolescence  issue  and  another  5-7  year  implementation  effort,  easily  exceeding  the  five- 
year  contract  period.  So  in  essence  we  are  continually  outdating  ourselves  because  we 
cannot  keep  up  with  commercial  technology  turnover.  Given  the  DoDD  5000  guidance 
and  the  institutionalized  budgeting  and  planning  process  for  appropriations,  the  only 
alternative  is  to  extend  supportability  for  those  near-obsolete  COTS  products  so  that  a 
more  effective  planning  and  execution  phase  can  take  place.  This  newly  developed 
scenario  should  provide  enough  flexibility  so  that  changes  during  the  acquisition  cycle 
will  have  minimal  impact  to  the  program. 

D.  CURRENT  STAKEHOLDER  ASSESSMENT 

1.  Program  Management  Office 

The  PMO  through  its  Integrated  Logistics  Support  (ILS)  group  orders  COTS 
assemblies  through  the  normal  support  systems  by  contract,  purchase  order,  or  Navy 
supply  system.  If  an  OEM  no  longer  supports  a  product,  then  the  PMO  must  look  for 
another  avenue  to  solve  the  issue,  typically  an  engineering  analysis  and  review  is 
necessary  yielding  a  variety  of  solutions  most  of  which  are  very  expensive.  If  the  PMO 
is  lucky  or  just  well  informed  (which  is  not  always  the  case),  the  OEM  will  provide  a 
notice  stating  an  “End  Of  Life”  (EOL)  date  after  which  the  OEM  will  no  longer  support 
the  specific  COTS  product.  At  this  point  the  PMO  must  make  some  choices.  Regardless 
of  the  choices  made,  the  PMO  incurs  a  significant  amount  of  risk  usually  at  a  hefty  price. 
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2.  Original  Equipment  Manufacturer  (OEM) 

The  OEM  is  usually  a  leading  edge  technology/design  firm  that  is  market  driven 
and  produces  at  high  volume  and  cost  reflective  of  commercial  economies  of  scale.  The 
fast  paced  environment  requires  short-lived  products  (-18-24  months)  to  keep  up  with  the 
ever-changing  technology.  The  business  case  is  just  not  there  to  cater  to  the 
DoD/government’s  needs  and  although  the  OEM  wishes  to  keep  this  group  of  consumers, 
the  momentum  of  the  business  cycle  keeps  the  OEM  focused  elsewhere.  Under  these 
circumstances  supportability  is  limited  to  production  run  time  (-18-24  months)  with 
approximately  a  12-month  follow-on  repair  and  test  capability  period. 

3.  Small  Business  (SSB  Supplier) 

The  SSB  supplier  is  envisioned  to  come  from  the  large  base  of  smaller  suppliers 
who,  over  the  past  three  decades,  have  provided  the  DoD/govemment  with  high  tech, 
custom  products.  Using  this  supplier  base  will  reduce  the  risk  caused  during  the 
technology  transfer  process  because  of  the  proven  track  record  earned  when  dealing  with 
other  DoD/govemment  products.  However,  this  will  be  a  collaborative  process  and  the 
final  decision  will  reside  with  and  between  the  OEM  and  the  SSB  supplier.  Here  the 
OEM  holds  the  trump  card  and  must  be  willing  to  live  with  the  choice.  The  small 
business  SSB  supplier  typically  has  extensive  technical  know  how  in  the  manufacturing 
area  but  lacks  the  expertise  to  accomplish  proactive,  predictive  obsolescence 
management.  These  companies  are  customer  focused,  agile,  and  seek  long-term 
relationships  with  their  customers. 

4.  DoD  Navy  Field  Activities/Resources 

Most,  if  not  all,  of  the  functions  identified  in  Figure  2  (17-Step  SSB 
Implementation  Process)  are  already  accomplished  by  internal  DoD/government 
resources;  however  they  are  done  in  an  ad-hoc  fashion  without  the  collaborative 
environment,  and  with  no  defined,  supportable,  and  repeatable  process  in  place.  The 
expertise  has  always  been  available  in  the  DoD/govemment  but  in  a  different  form  using 
a  different  process.  Prior  to  Acquisition  Reform,  the  MIL-Specs  and  standards  provided 
a  requirements-rich  environment  with  well-defined  processes  for  implementation.  These 
processes  and  implementation  methods  required  the  same  expertise  needed  today  but 
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applied  in  a  different  context.  Today’s  environment  is  requirements-poor,  and  the 
talented  expertise  must  adjust  to  this  perfonnance-based  versus  MIL-Spec-based 
environment.  The  context  in  today’s  environment  is  relationship-based,  not  rule -base, 
and  the  survivability  of  this  entire  group  of  talented  experts  will  depend  on  their 
adaptability  to  today’s  context.  Acquisition  Refonn  removed  the  barriers  put  in  place  by 
the  MIL-Spec,  rule-based  environment,  but  it  failed  to  provide  an  adequate  substitute, 
which  would  provide  a  robust  process  that  can  meet  the  supportability  requirements  and 
needs  of  the  end  user. 

E.  FUTURE  STATE  ASSESSMENT 

The  future  impacts,  as  a  result  of  SSB  implementation,  are  an  environment  where 
various  support  scenarios  are  defined  and  ready  for  service  to  the  particular  program.  A 
team  approach  is  envisioned  to  assess  the  current  program  state  in  terms  of  support  and 
performance  requirements.  They  will  also  evaluate  all  possible  mechanisms  for  reaching 
these  objectives.  This  team  effectively  perfonns  a  solution  analysis  for  a  particular 
program  and  produces  draft  scenarios  to  the  customer.  The  customer  examines  the 
scenarios  for  appropriateness  and  feasibility.  If  necessary,  the  scenarios  are  modified, 
expanded  upon,  rejected,  or  split  into  multiple  scenarios.  Identifying  various  life  cycle 
support  management  strategies  helps  the  PM  select  a  strategy,  which  best  fits,  their 
requirements.  Cost/risk  trade-off  and  availability  of  support  funding  play  major  roles  in 
determining  the  strategy  that  best  suites  each  individual  programs  requirement.  Proper 
life  cycle  management  of  military  weapons  systems  and  their  associated  product 
implementation  is  critical  when  commercial  products  are  used.  As  the  commercial 
product  content  of  military  systems  increases,  the  number  of  required  product  upgrades 
and  technology  refreshes  within  the  system  will  increase.  Engineering  changes  must  be 
processed  to  overcome  obsolescence  problems,  meet  new  performance  requirements,  or 
provide  more  cost  efficient  support.  Resolving  these  types  of  issues  requires  a  phased 
technology  management  approach  that:  assesses  the  technical  and  supportability  status  of 
current  equipment;  identifies  solutions  to  overcome  recognized  problems;  and  provides  a 
life  cycle  cost  analysis  to  detennine  the  costs  over  the  time  of  implementing  solutions. 

The  future  infrastructure  shall  address  the  development  of  a  cost  estimate  for 
technology  refresh.  Several  cost  estimating  tools  exist  for  system  life  cycle  costs  but  do 
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not  adequately  address  the  unique  cost  elements  of  a  technology  refresh.  A  cost  model 
that  is  effective  for  use  in  the  technology  assessment  process  must  be  designed  to  work 
whether  or  not  specific  system  hardware  or  software  has  been  chosen  and  project  costs 
for  items  that  may  not  exist  at  the  time  of  analysis.  In  order  to  accommodate  this, 
NAVSEA  Crane  Division  provides  a  technology  planning  and  management  cost  model 
that  uses  either  standard  cost  estimation  parameters  or  specific  cost  estimation 
parameters,  depending  upon  whether  specific  upgrade  hardware  has  been  chosen.  This 
concept  is  shown  in  Figure  8. 


Time 


Appendix  C  Figure  8:  Cost  Estimating  of  Support  Options 

The  costs  associated  with  multiple  platforms  and  shared  costs  associated  with 
common  platforms  are  taken  into  account  in  the  cost  estimate  by  identifying  the  different 
classes  of  platforms  and  the  number  of  occurrences  where  the  system  is  to  be  installed  on 
each  platform  class.  Commodity  consumption,  assets  on-hand,  and  replacement  cost 
data  are  used  when  determining  the  most  cost  effective  refresh  strategy.  For  example, 
insertion  of  new  COTS  equipment  may  allow  for  redistribution  of  available  repair  assets 
in  the  supply  support  pipeline,  thereby  solving  two  logistic  support  problems  with  one 
COTS  insertion. 

The  support  strategy  is  crucial  to  the  success  of  the  program  in  terms  of 
availability  and  readiness  as  well  as  cost.  In  fact  the  creation  of  various  support  strategies 
helps  to  quantify  refresh  costs.  The  refresh  costs  become  an  important  tool  in  identifying 
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a  preferred  method  of  replacement.  Typically,  three  solution  approaches  may  be 
portrayed  in  the  cost  estimate: 

•  Single  Item  Refreshes  -  The  costs  associated  with  single  item  replacements 
based  upon  market  trends.  The  target  dates  of  the  refreshes  are  approximate 
to  the  end  of  production  and  prior  to  end  of  support. 

•  Single  Block  Refresh  -  The  refresh  includes  all  items  within  the  configuration 
that  are  at  risk  due  to  availability  or  changes  in  mission  requirement.  A 
refresh  date  is  selected  and  costs  applied  to  implementation  of  the  change. 

•  Multiple  Block  refreshes  -  Blocks  of  items  are  defined  based  upon 
technological  trends  and  their  relation  to  functional  blocks  within  the  unit  or 
system  under  analysis.  Plans  are  established  to  refresh  these  blocks  over  the 
life  cycle  of  the  system.  Costs  are  applied  to  the  implementation  of  this 
approach  and  graphed  for  comparison  with  other  approaches. 

Additionally,  the  process  of  cost  estimating  can  be  used  as  a  program 
management  tool  to  identify  drivers  within  a  particular  refresh  approach  for  further 
analysis.  These  drivers  may  be  candidates  for  improvement  in  the  process  of  engineering 
and  supportability  analysis.  In  order  to  summarize  the  results  of  the  analysis,  a  model  is 
employed  that  totals  cost  estimates  and  compares  work  efforts  with  trends  and  known 
requirements.  The  model  is  a  simplified  representation  of  the  real  world,  which  abstracts 
the  features  of  the  situation  relative  to  the  problem  being  analyzed.  It  is  a  tool  employed 
by  the  analyst  to  assess  the  likely  consequences  of  various  alternative  courses  of  action 
being  examined.  The  model,  in  itself,  is  not  the  decision-maker,  but  is  a  tool  that 
provides  the  necessary  data  in  a  timely  manner  in  support  of  the  decision-making  process. 
It  is  a  way  to  let  the  collected  data  drive  the  decision  to  plan  for  a  technology  refresh. 
Specific  data  requirements  are  identified  from  the  evaluation  criteria  and  from  the  input 
requirements  of  the  model  used  for  evaluation  purposes.  The  objective  is  to  accomplish 
the  analysis  keeping  in  mind  the  interface  relationship  between  logistic  support  and  the 
hardware  or  software  choice  for  resolution  of  the  problem.  In  performance  of  the  cost 
analysis,  there  may  be  a  few  key  parameters  about  which  the  analyst  is  very  uncertain 
(due  to  inadequate  data,  pushing  the  state  of  the  art,  etc.).  Therefore,  the  analyst  will  run 
a  trade-off  analysis  in  which  the  model  is  run  several  times  using  different  key  input 
parameters  to  detennine  the  effect  on  the  results.  Variation  is  accomplished  by  applying 
different  multiple  factors  to  the  input  parameter  being  tested.  As  a  result,  the  analyst  will 
be  able  to  readily  detennine  whether  or  not  to  probe  further  in  an  effort  to  provide 
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improved  input  data  or  to  select  an  alternative  that  is  less  risky.  Inherent  in  the  process  of 
cost  analysis  is  the  aspects  of  risk  and  uncertainty  since  the  future  is,  of  course,  unknown. 
Risk  analysis  will  explore  these  various  aspects  and  document  assumptions  that  had  to  be 
made  in  completing  the  analysis. 

A  risk  analysis  is  performed  in  order  to  avoid  the  road,  which  leads  to  crisis 
management,  a  resource-intensive  process  that  is  normally  constrained  by  many 
obstacles.  An  up  front  look  into  the  associated  risks  of  different  solutions  allows 
planning  to  avoid  the  crisis  and  maintain  system  readiness.  Risk  is  considered  the 
probability  of  occurrence  of  a  particular  adverse  effect  upon  the  planning  and  estimating 
for  technology  management.  A  method  of  analysis  is  employed  to  quantify  variables 
associated  with  a  set  of  solutions  that  may  affect  the  outcome  of  planning.  In  other 
words,  the  process  of  developing  solutions  is  reviewed  to  determine  what  risks  are 
associated  with  each  solution  and  which  ones  are  significant.  These  risks  are  categorized 
as  low,  moderate  or  high  based  upon  their  likelihood  of  occurrence  and  the  potential 
impact.  Three  key  assumptions  are  made  that  are  at  risk: 

•  Failure  data  used  in  calculations  is  accurate  for  the  period  under  analysis, 

•  Life-cycles  for  commercial  products  used  to  set  technology  refresh  initiative 
dates  and  to  procure  bridge  buys  is  accurate 

•  System  operational  requirements  will  not  change  through  the  systems  life 
cycle  either  from  mission  requirement  changes  or  system  interoperability 
requirement  changes. 

If  failure  data  is  inadequate,  the  greatest  impact  will  be  to  schedule  in  terms  of  the 
application  platform  mission  readiness.  Quantities  procured  for  bridge  buys  would  be 
affected  by  individual  product  but  it  is  believed  that  the  aggregate  effect  would  be 
insignificant.  If  product  life  cycles  varied  from  those  used  in  planning,  both  the 
scheduling  of  technology  refreshes  and  bridge  buys  would  be  impacted.  This  is  again  a 
schedule  risk.  Finally,  if  the  system  operational  requirement  changes  due  to  changes  in 
the  mission  requirement  or  interfacing  systems  on  a  single  platform,  two  cost  impacts 
may  occur: 
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•  Quantities  of  bridge  buys  may  be  excessive  or  short  of  needs 

•  Engineering  estimates  for  implementing  a  technology  refresh  may  be  short  of 
requirements 

Reduced  government  funding  and  manpower  levels  have  further  emphasized  the 
need  to  improve  life  cycle  management  processes.  Perhaps  the  focal  point  for  this  effort 
is  COTS  risk  mitigation  during  development  and  for  fielded  weapon  systems.  This  type 
of  continual  assessment  is  needed  to  offset  the  fast  technology  update  cycle  experienced 
in  the  commercial  realm.  This  will  provide  system  baseline  configuration  stability  and 
supportability.  Key  to  this  is  the  need  to  continually  assess  original  equipment 
manufacturers.  This  assessment  should  provide  valuable  insight  to  the  vendor's  stability, 
which  in  turn  impacts  the  level  of  risk  associated  with  specific  components  employed  by 
the  DoD.  Such  assessments  would  perhaps  look  at  how  limited  a  vendor's  product  line  is 
and/or  make  judgments  on  the  potential  of  specific  products  in  that  line  to  change  or 
disappear.  To  this  end,  it  becomes  important  to  detennine  the  likelihood  that  a  vendor 
will  continue  to  provide  DoD  assets  and  the  consistency  of  that  product  line.  The 
challenge  is  in  the  architecting  of  a  process  that  is  proactive,  disciplined  and  systematic, 
and  will  consider  and  address  the  needs  as  discussed  here  for  the  intended  audience.  The 
audience  being  those  customers  or  stakeholders  whose  needs  must  be  fulfilled 
F.  FUTURE  STAKEHOUDERS  ASSESSMENT 

1.  Program  Management  Office 

The  collaborative  process  is  illustrated  in  Figure  9  and  shows  the  relationship  and 
informational  interfaces  between  the  PMO  and  the  other  identified  players. 
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Appendix  C  Figure  9:  Collaborative  Processes 

Figure  10,  Implementation  Process,  shows  the  process  flow  at  a  functional  level 
delineating  the  relationship  each  player  has  to  the  others  during  the  SSB  development. 
As  a  collaborator  in  this  process,  the  PMO  provides  the  funding  resources  to  internal 
government  activities  to  facilitate,  assess,  and  report.  Also,  the  PMO  is  agreeing  to  pay 
for  the  implementation  of  the  SSB  system  and  provide  the  Bill  Of  Material  (BOM)  for 
the  system  under  consideration.  For  their  efforts  the  PMO  receives:  1)  an  alternate  long 
tenn  supplier  of  the  COTS  product  and  a  relationship  with  that  supplier  and  their 
associated  OEM  that  may  be  extended  for  other  OEM  discontinued  items,  2)  as  identified 
in  Figure  9,  a  continuous  update  to  the  risk  identification  and  mitigation  efforts, 
proactively  adjudicating  obsolescence  issues  seamlessly  on  behalf  of  the  PMO,  3) 
provides  the  PMO  with  a  corporate  knowledge  data  base  on  which  future  decisions  can 
leverage,  4)  although  not  identified  through  the  figures,  the  program  gains  reparability 
and  testability  attributes  over  the  life  cycle  of  the  system  defined  by  the  Navy’s  needs. 
The  method  of  communication  being  online  is  nearly  in  real  time  so  the  effort  expended 
by  the  PMO  is  minimal.  Product  ordering  is  done  using  current  procurement 
methodologies. 
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Appendix  C  Figure  10:  Implementation  Process 

2.  Original  Equipment  Manufacturer  (OEM) 

The  OEM  for  their  part  in  the  collaboration  effort  has  a  lot  to  gain  and  little  to 
lose.  There  is  a  business  case  to  be  made  for  making  a  profit  from  their  intellectual 
property  they  no  longer  find  useful.  The  5-15%  royalty  is  the  incentive,  but  other  non¬ 
tangible  benefits  enhance  the  business  aspects  in  favor  of  the  collaboration  effort. 
Protection  of  their  proprietary  design  is  an  inherent  part  of  the  SSB  process  through 
“Non-Disclosure  Agreements  (NDA)”  and  contractual  mechanisms.  Important  to  note  is 
that  the  contractual  arrangements  are  made  with  another  company,  the  SSB  supplier,  not 
the  government,  which  many  OEMs  find  favorable  since  governmental  red  tape  would 
poison  the  business  case.  This  situation  leaves  the  ownership  and  control  of  the 
commercial  products  in  the  hands  of  the  industry.  Additionally,  the  government  does  not 
have  to  pay  for  the  design  only  the  product,  a  tenet  of  Acquisition  Refonn.  By 
participation  in  the  collaborative  system  the  OEM  establishes  a  long-term  relationship 
with  the  DoD/government  without  the  ongoing  supportability  issues.  In  turn  these  new 
emergent  properties  of  the  system  can  be  used  to  enhance  the  ability  of  the  OEM  to 
market  enhanced  product  supportability,  not  only  to  the  DoD/government  environment, 
but  also  any  entity,  which  is  configuration  constrained  due  to  the  business  constraints  (i.e. 
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refineries,  paper  mills,  electrical  power  generation  and  control  applications,  etc.).  The 
OEM  efforts  are  concentrated  during  the  establishment  of  the  SSB  supplier  and  play  a 
crucial  part  in  assuring  that  the  OEM  reputation  will  be  in  safe  hands  when  the  SSB 
supplier  delivers  products.  The  OEM  however  does  agree  to  allow  the  internal  Navy 
resources  visibility  into  the  products  design  by  letting  the  SSB  supplier  share  the  parts  list 
complete  with  associated  component  vendor  information  along  with  a  top  level  assembly 
drawing.  This  is  information  the  government  has  not  been  privy  to  in  the  past  but  it  is 
essential  for  accomplishment  of  risk  analysis  and  yielding  the  desired  emergent 
properties  of  the  system. 

3.  Small  Business  Supplier  (Sunset  Supplier) 

As  for  their  part  in  the  collaboration  process,  the  SSB  supplier  must  be  willing  to 
be  contractually  bound  by  the  agreement  with  the  OEM  and  at  the  same  time  be  willing 
to  work  the  internal  government  resources  to  coordinate  and  facilitate  supportability 
efforts  while  reducing  risk  to  the  program.  Actions  required  by  the  SSB  supplier  will 
include: 

•  Sharing  the  OEM  parts  list  and  drawings. 

•  Be  the  purchaser,  stock  handler,  and  storage  facility  for  parts  that  have  gone 
obsolete  and  are  awaiting  consumption  once  an  assembly  order  is  placed. 

•  As  requested  by  the  program,  be  willing  to  stock  all  up  assemblies  (which 
have  already  been  paid  for)  to  enable  immediate  turnaround  times  of  fielded 
assemblies,  which  have  failed. 

•  Accept  all  the  responsibility  for  being  the  prime  supplier  of  the  subject 
assembly. 

In  return  for  its  efforts  the  SSB  supplier  is  rewarded  through: 

•  A  new  relationship  with  a  pre-eminent  commercial  firm. 

•  A  new  product  line. 

•  New  customers,  DoD/govemment  and  non-government. 

•  Long  tenn  relationships  with  the  new  customers  which  enables  long  term 
business  planning. 

•  Technical  partnering  with  internal  DoD/government  resources  not  only  for 
predictive  obsolescence  management  but  a  whole  host  of  other  specialties. 
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4. 


DoD  Field  Activities/Resources 


The  internal  DoD/government  resources  have  a  very  crucial  role  to  play  regarding 
the  supportability  of  all  our  systems  from  design  to  fielded  systems.  Supportability  is  an 
inherently  governmental  function  for  several  reasons:  1)  the  motivation  of  our  internal 
resources  is  in  support  of  the  end  user  needs;  this  perpetuates  and  enhances  our  positions 
and  esteem,  2)  due  to  the  overarching  scope  and  the  long  term  broad  based  characteristics 
of  supportability  issues,  no  one  prime  contractor  could,  without  conflict  of  interest, 
accomplish  these  functions,  and  3)  No  entity  has  or  even  wishes  to  obtain  the  corporate 
knowledge  maintained  by  our  internal  resource  pool.  The  collaborative  environment  as  is 
evident  in  Figures  1,  9  and  10  embeds  the  talented  expertise  into  the  SSB  process  in  a 
way,  which  leverages  these  resources  and  creates  a  value  stream  for  the  program.  The 
relationship  building  characteristics  of  our  internal  resources  is  very  evident  in  Figure  9 
where  this  crucial  resource  takes  “center  stage”  in  enabling  the  collaborative  system. 
Taking  both  figures  (1  &  9)  in  concert  it  is  easy  to  see  how  the  resource  can  gain  program 
equity  and  support  by  reducing  life  cycle  costs  (LLC),  extending  supportability  of 
systems,  and  reducing  program  risk 
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XI.  ANALYSIS 


A.  BUSINESS  IMPACTS 

In  this  section  the  potential  financial  consequences  will  be  presented  along  with 
specific  areas  of  benefit  to  the  business  process.  An  analysis  of  the  cost  data  will  be 
presented  in  the  form  of  data  summaries  in  an  effort  to  answer  the  questions  stated  at  the 
beginning  of  this  document.  The  data  will  be  offered  in  an  objective  and  direct  manner 
so  as  to  keep  interpretations  and  explanatory  text  to  a  minimum.  This  section  will 
address  the  direct  financial  impacts  as  well  as  contributions  they  make  to  the  business 
objectives.  And  finally,  an  alignment  between  the  financial  model  and  the  business  needs 
will  be  offered  that  will  provide  a  summary  of  results,  to  include  non-financial  impacts, 
as  well  as  a  statement  on  feasibility. 

B.  FINANCIAL  MODEL 

The  purpose  of  the  financial  model  is  to  collect,  manage,  and  analyze  cost  data. 
In  this  way,  the  model  essentially  converts  the  data  into  infonnation  in  a  convenient  and 
easily  understood  format.  For  this  business  case  we  are  looking  at  the  life  cycle  costs 
(LLC),  over  a  10-year  period.  LLC  estimates  are  typically  given  for  the  life  cycle  of  a 
system  and  in  particular  for  capital  programs.  The  LLC  usually  provides  the  total  cost  of 
acquiring,  installing,  using,  changing  and  disposal  across  the  entire  life  of  the  system.  In 
this  case,  we  target  only  the  period  between  technology  refresh  dates.  This  specific 
interval  (i.e.,  time  periods  between  initial  fielding  of  the  equipment  and  the  next 
technology  refresh)  is  the  appropriate  application  for  SSB  System’s  use.  Since  it  was 
designed  specifically  for  these  intervals,  the  SSB  System  provides  the  largest  potential 
benefit  to  the  program.  The  SSB  process,  as  stated  previously,  is  meant  to  stabilize  the 
system  baseline  between  technology  refresh  dates  and  thereby  ensure  supportability  for 
this  period.  The  program  management  team  determined  the  10-year  cycle.  Nevertheless, 
similar  cost  data  could  have  been  derived  and  analysis  perfonned  for  any  technology 
refresh  period.  The  infonnation  presented  in  this  section  ( Financial  Model )  addresses 
only  the  costs  aspects  of  supporting  the  SSDS  under  different  scenarios.  In  this  way,  the 
analysis  will  provide  expected  future  support  costs  for  budgetary  planning  purposes,  as 
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well  as  identify  potential  problems  or  opportunities.  Non-financial  benefits  will  be 
offered  in  subsequent  sections.  Together  they  support  the  decision-making  process  that 
leads  to  the  most  effective  supportability  strategy. 

Six  different  support  scenarios  were  prepared  by  running  the  Cost  Model  using 
the  SSDS  MK  1  data  set.  A  scenario  consists  of  a  chosen  combination  of  the  various 
support  methods  for  each  COTS  item,  the  three  choices  included:  Life  of  Type  Buy  - 
LTB,  Sunset  Supply  Base  -  SSB,  or  Refresh.  These  scenarios  were  put  into  two  groups 
for  side-by-side  comparison  (within  a  group)  of  impacts  due  to  type  of  support  chosen. 

The  first  group  consisted  of  three  scenarios,  each  on  a  separate  worksheet  in  the 
Cost  Model  workbook  of  Enclosure  (28)  labeled  with  the  following  names  -  LTB(l), 
SSB(l),  SSB  optimized.  These  scenarios  varied  the  amount  of  involvement  the  SSB 
system  was  employed,  as  evident  through  the  following  descriptions: 

1)  LTB(l)  -  Is  a  bridge  buy  of  all  procurable  COTS  products,  NO  SSB  used 

2)  SSB(l)  -  Is  the  scenario  that  the  SSDS  COTS  Working  Group  decided  to 
execute.  Implementation  SSB  system  at  75%  of  potential  candidates. 

3)  SSB  optimized  -  Reflects  the  implementation  of  SSB  process  for  all  presently 
procurable  COTS  products  and  where  the  OEMs  were  willing  to  participate, 
this  would  represent  100%  SSB  system  utilization  with  the  given  constraints. 

The  second  group  presented  the  exclusive  use  of  only  one  of  the  support  methods 
at  a  time  showing  the  global,  aggregate  impact  on  the  supportability  costs  over  the 
interval.  Due  the  constraints  on  the  SSDS  MK  1  many  of  these  support  choices  are  not 
feasible  but  the  comparison  is  provided  to  show  a  notional  impact  if  given  the  right 
constraints  what  the  potential  outcome  would  be.  Identification  of  these  worksheet 
names  in  Enclosure  (28)  and  potential  cases  for  using  these  support  methods  are  as 
follows: 

1)  LTB  only  -  LTB  used  for  all  COTS  products,  NO  SSB  &  NO  REFRESH.  This 
type  of  support  method  is  sometimes  used  at  the  beginning  of  a  systems  life  to 
insure  supportability  over  a  given  period. 

2)  SSB  only  -  SSB  used  for  all  COTS  products,  NO  LTB  &  NO  REFRESH.  This 
type  of  support  method  must  be  implemented  before  irreversible  obsolescence 
takes  place  on  any  of  the  items,  typically  this  would  be  done  as  soon  as  possible 
after  a  design  baseline  is  defined. 
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3)  Refresh  only  -  “Refresh  only”  reflects  a  situation  where  a  program  will  chase 
the  changing  technology,  resulting  in  a  redesign  every  time  a  COTS  product 
becomes  obsolete.  These  obsolescence  dates  are  identified  by  the  End-of- 
Production  (EOP)  dates,  information  published  by  the  OEM  and  documented  in 
Enclosure  (28).  This  type  of  support  solution  typically  necessitates  an  open 
systems  architecture  to  be  cost  effective. 

Financial  models  were  developed  for  the  use  of  evaluating  the  impact  of 
implementing  various  support  options  given  the  SSDS  MK1  data  set.  The  Financial 
Models  were  primarily  derived  using  the  Cost  Model,  identified  in  a  previous  section  of 
this  BCA,  with  four  additional  constraints  requiring  manually  calculated  cost  data.  These 
four  cost  areas  are  explained  in  the  subsequent  text  as  Variants  1-3  and  “Red  Parts”  costs. 
This  additional  infonnation  allows  modification  of  the  general  Cost  Model  to 
accommodate  for  special  program  needs  or  implementation  of  alternative  risk  mitigation 
methods  (i.e.  ECP,  ISEA  actions).  In  assigning  a  support  method  to  the  affected  COTS 
products  covered  by  one  of  the  “Variants”  a  label  of  “Other”  is  given  to  them  in  the 
worksheet  column  “Support  Method”  of  Enclosure  (28).  Taking  the  Cost  Model  outputs 
and  combining  them  with  this  additional  infonnation  adequately  describes  the  cost 
impact  in  supporting  the  SSDS  MK  1  over  the  10  year  support  window.  Enclosure  28 
merges  all  costs  together  to  provide  the  total  supportability  costs  over  the  10  year 
interval. 

1.  First  Variant 

The  COTS  products  that  have  been  detennined  to  be  near  obsolete  and 
unsupportable  must  be  redesigned.  Enclosure  (30)  (Resource  Cost  Models,  worksheet 
‘Required  Tech  Refresh’)  provides  the  resource  cost  model  for  those  COTS  products  that 
will  have  to  be  replaced  in  the  2005-6  timeframe  and  bridge  buys  are  not  possible.  Based 
on  market  surveillance,  NSWC  Crane  determined  that  nine  COTS  products  are  affected. 

1)  Ay  din  19"  CRT  Monitor  (replaced  with  flat  panel) 

2)  4  mm  DAT  Drive  (replaced  with  similar  product) 

3)  Electro  Luminescent  Panel  (replaced  with  similar  product) 

4)  Ethernet  Network  Card  (VLANME2  being  refreshed  to  VLANME3) 

5)  Red  Rock  2. 1  G  drive  (replaced  with  next  generation  product) 

6)  FDDI  DAS  replacement  (pulling  half  of  the  cards  in  each  configuration  and 
replacing  with  slot  bypass  boards) 

7)  Concentrator  replacement  (pulling  half  of  the  cards  in  each  configuration  and 
replacing  with  slot  bypass  boards) 
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8)  NTDS  Type  A/B  (replacing  530-2000-00 l's  and  530-2005-00 l's  with  530- 
3000-001) 

9)  Red  Rock  Dual  DAT  (replaced  with  next  generation  product). 

The  SSB  process  team  has  deemed  these  items  as  OTHER  and  a  redesign  effort  to 
accommodate  replacement  of  these  items  is  necessary.  This  worksheet  represents  a 
simulation  model  to  estimate  the  potential  cost  impact  of  all  nine  items  that  require 
technical  refresh/insertion,  which  means  implementing  a  new  design  or  configuration. 
The  following  table  is  taken  from  the  worksheet  and  shows  the  total  cost  for  each  WBS 
element  and  a  total  additional  cost  to  the  program  of  $7.063M. 


WBS  Element 

Total  ($K) 

Total 

7063 

Configuration  Management 

126 

Hardware/Software  Engineering 

1684 

Testing  And  Documentation 

944 

Procurement 

3866 

IFS  Planning  and  Management 

337 

Installation 

107 

Appendix  C  Table  2:  Total  Support  Costs  (Required  Tech  Refresh,  9  Items) 

This  amount  is  essentially  the  total  cost  to  replace  all  nine  items  through  analysis, 
redesign  and  installation  in  the  Fleet  The  SSB  process  was  not  applied  to  these  COTS 
products  as  a  cost  avoidance  measure  because  of  timing.  By  the  time  the  SSB  concept 
was  implemented  for  the  SSDS  MK  I,  commitment  was  made  to  replace  these  items  with 
a  redesign.  Subsequently  this  cost  must  be  added  to  all  three  scenarios  to  get  a  total  cost 
of  support  over  the  ten-year  cycle. 

2.  Second  Variant 

For  each  worksheet  in  the  procurement  model  there  is  a  value  of  $1,300,000 
under  Sub-Total  for  Program  Year  1  as  shown  below. 
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Program  Year  1 

Supplier  Part  # 

Support  Method 

#  Buy 

Sub- Total- $  Cost 

PT-VME610A- 

10534 

OTHER 

0 

$1,300,000.00 

Appendix  C  Table  3:  Engineering  Change  Proposal  Costs:  Second  Variant 


This  value  is  based  on  preliminary  data  detennined  from  actual  Navy  supply 
research  by  the  In-Service  Engineering  Activity  (ISEA),  NSWC  Port  Hueneme  and  is  a 
conservative  estimate  of  implementing  an  Engineering  Change  Proposal  (ECP)  to 
perform  engineering  analysis,  design,  test  and  installation  in  the  Fleet. 

3.  Third  Variant 

For  each  worksheet  in  the  procurement  model  there  is  a  value  of  $102,877.00 
identified  as  Total  Other  (Misc.)  for  all  cost  matrices. 


Total 

$5,820,641.00 

Total  Other 
(Misc.) 

$102,877.00 

FY  03  Total 

$5,923,518.00 

Total  Red  Parts 

Net  Present  Value 

$6,795,517.54 

Appendix  C  Table  4:  Miscellaneous  Costs:  Third  Variant 

This  value  comes  from  the  worksheet  titled  ‘Special  Data  for  MK  This  value 
represents  the  costs  associated  with  the  items  that  are  not  covered  in  the  cost  matrices: 
and  not  part  of  the  ‘ SSDS  Master  Assembly  List’  worksheet.  These  items  are  unique  and 
must  be  purchased  to  support  the  program.  Consideration  is  being  given  to  extending  the 
SSB  concept  to  these  items  at  the  request  of  the  PMO.  These  items  tended  to  be  low  cost 
and  supported  by  a  bridge  buy.  This  figure  is  found  in  all  procurement  cost  matrices. 

4.  Red  Parts 

Red  Parts  are  those  items  that  are  dangerously  close  to  being  obsolete  and  must  be 
purchased  in  order  to  support  the  production  of  the  COTS  product. 
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Total 

Total  Other 
(Misc.) 

$102,877.00 

FY  03  Total 

$3,058,736.27 

Total  Red 
Parts  Cost 

$520,240.57 

Net  Present 
Value 

$6,021,954.17 

Appendix  C  Table  5:  Red  Parts  Cost  Example 


The  Red  Parts  cost  for  FY03  was  calculated  from  the  aggregate  of  all  ‘Red  Parts’ 
costs  for  each  COTS  configuration.  This  value  is  presented  in  Enclosure  (28)  “SSDS 
Assembly  Master  and  Cost  Matrices”  in  column  I.  Our  implementation  experience  has 
shown  that  the  rate  of  increase  of  obsolete  parts  (Red  Parts)  increases  at  the  average  rate 
of  approximately  5%  per  year.  To  account  for  this  increase  in  future  years,  we  have 
projected  that  this  increase  could  provide  a  good  estimator  for  the  amount  of  budget 
needed  in  the  out  years. 

As  evident  in  the  procurement  cost  models,  the  FY  dollars  needed  each  year  is 
calculated  as  follows: 

[We  will  use  worksheet  ‘SSB  (1)'  values  to  demonstrate] 

FY03  =  $520,240.57 

FYO  4  =  ($520,  240 . 57)  (0 . 05)  =  $26,012.03 

FY05  =  ($520,  240.57  +  $ 2 6 ,  0 12 )  (  0 . 05 )  =  $27,31.63 

FYO  6  =  (FYO  3  +  FY04  +  FY05)  (0.05)  =  $28,  678.26 

FY1 2  =  (FYO 3  +  FY 0 4  +  -----  +  FY11)  (0.05)  =  $38,  431.61 

In  an  effort  to  compare  same  year  dollars  from  different  scenarios  spread  over  the 
10  year  interval,  calculations  of  Net  Preset  Value  (NPV)  were  done  to  compare  the 
support  costs  in  FY  03  dollars.  NPV  calculations  were  based  on  a  rate  of  5.1%  across  the 
period  of  analysis  as  required  per  OMB  Circular-A94.  [32)  OMB] 
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There  are  two  enclosures  from  which  we  have  derived  the  following  results. 

•  Enclosure  (28)  -  SSDS  Assembly  Master  and  Cost  Matrices  -  provides  the 
detailed  procurements  costs  for  each  scenario. 

•  Enclosure  (30)  -  Resource  Cost  Models  -  provides  the  detailed  resource 
costs  needed  to  set  up  and  maintain  each  scenario. 


The  procurement  costs  for  the  resource  cost  models  was  derived  from  the 
procurement  costs  calculated  in  Enclosure  (28).  In  this  way,  the  two  enclosures  are 
linked  and  represent  a  consistent  picture  of  the  costs  needed  to  execute  this  analysis. 


Sunset  Supply  Costs 

8404 

Operations  Cost 

1550 

Component  Surveillance 

650 

Sunset  Supply  Industry  Interface 

650 

Sunset  Supply  Set  Up 

Procurements  ( 

6854  / 

Red  Parts  Cost  (5%  of  inventory  per 
year) 

Procurements  of  Replenishment 

Spares 

6567 

Taken  from  Enclosure  (30) 

Appendix  C  Table  6:  Procurement  Cost  Example 


0.038%  error 


/ftPV  Total  N 

$6,021,954.17 

Grand  Total 

$6,851,397.68) 

Taken  from  Enclosin' 


One  final  note,  for  each  scenario  (LTB(l),  SSB(l)  and  SSB  Optimized)  there  is 
an  additional  cost  of  $701,217  for  consumed  inventory.  This  is  the  amount  that  has 
already  been  invested  for  providing  spares.  This  amount  will  be  considered  when  we 
address  total  support  cost  in  the  Analysis  of  Results  section. 

C.  RESULTS 


As  previously  mentioned,  there  is  a  cost  ($7.063M)  associated  with  ‘Required 
Tech  Refresh’  that  must  be  included  for  each  of  the  three  scenarios  1)  LTB(l),  2)  SSB(l), 
and  3)  SSB  Optimized  to  get  an  overall  cost  to  support  the  SSDS  over  the  ten-year 
period.  Since  this  cost  is  unchanged  due  to  the  scenario,  we  have  excluded  from  this  part 
of  the  results  discussion.  The  focus  here  will  be  on  the  total  support  costs  and 
procurement  costs  minus  the  costs  due  to  a  required  technical  refresh  or  redesign. 

All  cost  figures  are  given  in  $K, 
unless  otherwise  stated. 
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The  first  chart  illustrates  the  total  support  costs  due  to  implementing  a  given 
method. 


Chart  1:  Total  Support  Costs  (LTB  (1),  SSB  (1),  SSB  Optimized) 

The  overall  total  support  cost  is  highest  when  implementing  the  LTB(l)  method. 
Implementation  of  SSB  (actual  or  optimized)  provides  a  cost  reduction  of  approximately 
15%  as  compared  to  a  traditional  LTB  approach. 

If  we  look  at  how  these  costs  are  allocated  over  the  ten-year  period  we  get  the 
following  profile. 
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Annual  Total  Costs 


□  LTB(1) 


■  SSB(1) 


□  SSB  Optimized 


Chart  2:  Annual  Total  Costs  (LTB  (1),  SSB  (1),  SSB  Optimized) 


The  funding  profile  for  the  LTB(l)  approach  not  only  has  a  greater  total  support 
cost,  it  also  incurs  the  majority  of  this  cost  upfront  with  a  very  erratic  funding  profile  for 
the  remaining  years.  The  next  two  charts  emphasis  these  two  facts. 


Chart  3:  Total  Initial  Cost  (LTB  (1),  SSB  (1),  SSB  Optimized) 


335 


Chart  4:  Remaining  Annual  Costs  (LTB  (1),  SSB  (1),  SSB  Optimized) 

The  LTB  (1)  approach  is  burden  with  more  then  half  of  the  overall  costs  in  the 
first  year  (see  graph  below)  and  has  a  more  unstable  funding  profile  in  the  remaining 
years.  This  instability  affects  the  planning  and  budgeting  process  executed  at  the 
beginning  of  the  period. 

Initial  Cost  as  a  Percentage  of  Total  Cost 


80% 


□  LTB(1)  dSSB(1)  □  SSB  Optimized 


Chart  5:  Initial  Cost  as  a  Percent  of  Total  (LTB  (1),  SSB  (1),  SSB  Optimized) 
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The  total  support  cost  consists  of  two  major  sources:  1)  procurement  of  the 
hardware,  and  2)  the  resources  needed  for  managing  the  system  configuration, 
engineering  tasks,  testing,  documentation,  ILS  planning  and  management,  and 
installation. 

The  following  chart  breaks  down  the  total  support  cost  into  procurement  and 
resources. 


Chart  6:  Total  Support  Costs  (LTB  (1),  SSB  (1),  SSB  Optimized) 

From  the  above  graph,  we  see  that  the  procurement  costs  contributes  significantly 
more  than  the  resource  costs. 

Focusing  on  the  procurement  costs  we  get: 
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Total  Procurement  Costs 

$7,200  -r -  - 

$7,000  - - - - 

$6,800  -  “  - 

$6,600  -  - 

$6,400  - 

$6,200  - 

$6,000  -  - 

$5,800  -  - 

$5,600  - 

$5,400  \ - - ^ - - 1 - 

Total  Cost  NPV  Total 

□  LTB(1)  □SSB(1)  □  SSB  Optimized 


>-$S00K 


Chart  7:  Total  Procurement  Cost  (LTB  (1),  SSB  (1),  SSB  Optimized) 

Through  further  inspection  we  see  that  the  procurement  costs  for  the  LTB(l)  is 
also  larger  than  for  the  SSB  methods.  Furthermore,  the  NPV  values  are  significantly 
lower  for  the  SSB  methods.  This  leads  us  to  conclude  that  the  costs  for  these  two 
approaches  will  be  spread  out  over  the  ten-year  period.  In  fact  the  following  chart 
confirms  this. 
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Annual  Procurement  Costs 
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Chart  8:  Annual  Procurement  Costs  (LTB  (1),  SSB  (1),  SSB  Optimized) 


From  the  above  chart,  we  see  that  the  procurement  costs  for  the  LTB(l)  are 
primarily  incurred  in  the  first  year,  typical  for  bridge  buy  scenarios.  The  SSB  methods 
have  lower  initial  costs  and  share  the  remaining  costs  with  the  remaining  years.  The  next 
two  graphs  break  out  the  initial  costs  and  the  remaining  years. 


Chart  9:  Initial  Procurement  Costs  (LTB  (1),  SSB  (1),  SSB  Optimized) 
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Chart  10:  Remaining  Initial  Procurement  Cost  (LTB  (1),  SSB  (1),  SSB  Optimized) 

The  important  points  to  make  here  is  that  the  SSB  methods  require  less  upfront 
costs,  spreads  the  remaining  costs  out  over  the  rest  of  the  support  period,  and  deliver  a 
more  stabilized  funding  profile  for  the  remaining  years  as  depicted  by  the  trend  lines  in 
the  above  graph.  The  amount  of  the  initial  procurement  costs  invested  in  each  scenario  is 
illustrated  below. 


Initial  Procurement  Cost  as  a  Percentage  of 
Total  Procurement  Cost 

100%  - 
90%  - 
80%  - 
70%  - 
60%  - 
50%  - 
40%  - 
30%  - 
20%  - 
10%  - 
0%  - 

Total  NPV  Total 

□  LTB(1)  ■  SSB(1)  □  SSB  Optimized 


Chart  11:  Initial  Procurement  Cost  as  a  Percentage  of  Total  Procurement  Cost  (LTB  (1),  SSB  (1), 
SSB  Optimized) 
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The  above  graph  clearly  shows  the  level  of  commitment  needed  to  initiate  a 
particular  support  method.  For  completeness,  the  procurement  costs  for  the  remaining 
years  as  a  percentage  of  the  total  procurement  costs  is  given  below,  again  emphasizing 
the  stability  of  the  funding  profiles  for  the  SSB  implementations. 


Chart  12:  Remaining  Procurement  Costs  as  a  Percentage  of  Total  (LTB  (1),  SSB  (1),  SSB  Optimized) 

As  earlier,  for  each  scenario  presented  above  an  additional  cost  must  be 
considered  due  to  those  items  that  are  planned  to  undergo  a  redesign.  The  amount  of 
$7.063M  must  be  considered  in  presenting  a  complete  picture  of  cost  for  each  scenario. 


WBS  Element 

Total  ($K) 

Total 

7063 

Configuration  Management 

126 

Hardware/Software  Engineering 

1684 

Testing  And  Documentation 

944 

Procurement 

3866 

ILS  Planning  and  Management 

337 

Installation 

107 

Appendix  C  Table  7:  Work  Breakdown  Structure  Element 

Part  of  this  total  cost  is  also  procurement  in  the  amount  of  $3.866M.  These 
amounts  are  constant  between  all  three  scenarios  and  therefore  excluded  from  the  results 
in  order  to  focus  on  the  actual  contributions  of  each  support  method.  This  redesign  effort 
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is  essentially  a  technical  refresh  task  required  for  those  COTS  products  that  cannot  or 
have  been  chosen  not  be  supported  by  either  the  LTB  or  SSB  mechanisms. 

In  order  to  avoid  this  technical  refresh  and  its  subsequent  costs  the  PMO  would 
have  to  employ  the  LTB  or  SSB  methods  from  the  beginning  or  consider  a  complete 
redesign  of  the  entire  SSDS.  In  this  next  section  we  will  look  at  supporting  the  SSDS  by 
three  additional  scenarios  in  order  to  avoid  the  technical  refresh  that  would  otherwise  be 
required  as  mentioned  above.  These  additional  scenarios  are: 

1)  LTB  for  all  COTS  products  over  the  ten-year  period. 

2)  SSB  for  all  COTS  products  over  the  ten-year  period. 

3)  A  complete  redesign  of  the  system. 

The  following  graphs  will  help  depict  the  cost  structure  for  each  scenario.  This 
first  graph  shows  the  total  cost  of  implementing  any  of  the  three  support  methods. 


$80  nnn 

Total  Support  Cost 

<£7n  nnn 

$fin  nnn 

nnn 

<&d.n  nnn 

<Knn  nnn 

‘fcpn  nnn 

$10,000  - 

<fcn 

:i 

Total 

■  LTB  Only  □  SSB  Only 

NPV 

□  Complete  Tech  Refresh 

Chart  13:  Total  Support  Cost  (LTB  Only,  SSB  Only,  Complete  Tech  Refresh) 

It’s  not  hard  to  see  that  a  complete  redesign  or  technology  refresh  is  by  far  the 
most  expensive  method.  This  is  anticipated  considering  all  of  the  elements  that  must  be 
funded.  The  following  chart  shows  the  elements  and  their  contribution  to  this  particular 
effort. 
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Complete  Technology  Refresh 
($K) 


□  Configuration 
Management 

■  Hardware/Software 
Engineering 

□  Testing  And 
Documentation 

□  Procurement 

■  ILS  Planning  and 
Management 

□  Installation 


Ch^rtTzffComplete  Technology  Refresh  (Cost  Allocation) 

In  addition  to  a  huge  procurement  cost  ($54. 7M),  notice  the  engineering  costs  at 
$10.5M.  This  amount  is  greater  than  the  total  cost  of  either  of  the  other  two  methods. 


$107 


Chart  15:  Annual  Total  Costs  (LTB  Only,  SSB  Only,  Complete  Tech  Refresh) 


343 


The  annual  costs  are  shown  above.  The  majority  of  the  costs  for  a  complete 
redesign  occur  in  2004,  2005  and  2006.  These  amounts  are  significant  and  are  based  on 
proper  planning  in  year  2003.  What  this  implies  is  that  poor  planning  can  cause  these 
figures  to  increase;  therefore  a  great  deal  of  risk  is  assumed  if  this  scenario  were 
executed. 

As  with  other  scenarios,  procurement  costs  make  up  the  majority  of  the  overall 
costs.  The  following  graph  illustrates  the  contributions  of  procurement  and  required 
resources  to  the  total  support  costs. 


Chart  16:  Total  Support  Cost  (LTB  Only,  SSB  Only,  Complete  Redesign) 

In  each  case,  procurement  costs  are  the  overriding  contributor  to  overall  costs  and 
a  complete  technology  refresh  requires  huge  procurement  dollars.  This  is  easy  to 
understand  since  this  effort  is  outfitting  the  entire  fleet  where  the  other  two  scenarios  are 
simply  replacing  anticipated  failed  COTS  products.  The  next  graph  illustrates  the 
procurement  impact  for  each. 
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Chart  17:  Total  Procurement  Costs  (LTB  Only,  SSB  Only,  Complete  Tech  Refresh) 

Needless,  to  say,  a  tremendous  amount  of  investment  in  hardware  is  needed  to 
support  this  scenario. 

Furthermore  this  investment  is  made  early  in  the  ten-year  period.  This  brings  us 
back  to  a  recurring  theme,  which  is  hardware  procured  early  is  likely  to  be  obsolete  by 
the  time  you  reach  the  end  of  the  ten-year  period  when  it  is  to  be  installed.  From  the 
illustration  in  Chart  15,  significant  expense  is  incurred  in  the  2005  and  2006  timeframe 
for  tech  refresh.  This  is  3-5  years  before  we  expect  to  install. 

From  this  point  forward  we  will  exclude  the  Complete  Technology  Refresh 
scenario  as  a  reasonable  choice  simply  because  of  the  large  cost  associated  with  it.  In 
doing  so  we  assume  that  the  benefits  derived  from  a  complete  tech  refresh  is  not  worth 
the  costs,  because  when  driven  by  COTS  obsolescence  cycles  these  refresh  costs  reoccur 
every  2-5  years  unless  supported  with  other  support  alternatives  like  SSB  or  LTB.  We 
will  now  concentrate  on  the  remaining  two  scenarios  of  LTB  Only  and  SSB  Only.  In 
order  to  simplify  the  graphs,  the  LTB  Only  and  SSB  Only  will  be  replaced  by  LTB  and 
SSB  respectively.  The  Total  Support  Costs  for  each  are  indeed  comparable,  as  seen  from 
the  below  graph. 
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Chart  18:  Total  Support  Cost  (LTB,  SSB,  NPV  LTB,  NPV  SSB) 


At  first  glance,  it  looks  like  the  SSB  approach  is  slightly  more  expensive  overall, 
but  applying  Net  Present  Value  we  see  it  actually  costs  less.  The  following  graphs  will 
help  us  to  understand  why  this  is  so.  Looking  at  the  annual  costs  we  see  two  familiar 
attributes  of  the  SSB  method: 

1)  Lower  Initial  Cost  2)  Costs  are  spread  out  more  evenly. 
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Chart  19:  Annual  Procurement  Costs  (LTB,  SSB) 
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The  next  graph  targets  specifically  the  initial  cost. 


Total  Initial  Procurement  Costs 

$6,000  n 

$5,000  - 
$4,000  - 
$3,000  - 
$2,000  - 
$1,000  - 
$0  - 

■  LTB  □  SSB 

Chart  20:  Total  Initial  Procurement  Cost  (LTB,  SSB) 

The  LTB  method  must  invest  nearly  $3.9M  more  in  the  first  year  than  the  SSB 
method. 

In  terms  of  overall  costs  the  following  provides  the  percent  of  total  procurement 
cost  that  has  to  be  invested  in  the  first  year  (2003). 


Initial  Procurement  Cost  as  a  Percent 
of  Total  Procurement  Costs 


90%  n -  81.78% 


■  LTB  □  SSB 


Chart  21:  Initial  Procurement  Cost  as  a  Percentage  of  Total  Procurement  Costs  (LTB,  SSB) 
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Nearly  82%  of  the  total  procurement  costs  for  LTB  are  allocated  in  the  first  year. 
This  introduces  significant  risk  to  the  program.  The  number  of  COTS  products  procured 
is  based  on  failure  rate  analysis  data.  This  investment  essentially  locks  the  PM  in  for  the 
duration  of  the  ten-year  period  with  little  flexibility.  Additionally,  conservative  failure 
rate  estimates,  that  is  high  failure  rates  must  be  used  in  order  to  ensure  the  COTS  items 
can  be  supported  for  the  entire  ten  years.  The  SSB  on  the  other  hand  invests  less  than 
18%,  which  results  in  spreading  out  the  costs  over  the  out  years.  The  following  graph 
illustrates. 


Chart  22:  Remaining  Years  Annual  Procurement  Cost  (LTB,  SSB) 

Less  investment  is  needed  up  front,  leading  to  larger  expenditures  in  the  later 
years.  First  of  all,  less  up  front  expense  results  in  lower  risk  and  more  flexibility.  The 
flexibility  comes  from  the  fact  that  you  have  more  of  the  total  allocated  dollars  for  the 
program  not  invested.  Secondly,  each  subsequent  year’s  costs  are  higher  but  with  each 
passing  year  the  risk  associated  with  expenditures  is  lower  as  we  approach  the  end  of  the 
ten-year  period.  Also,  procurement  costs  are  associated  with  actual  failures  for  that  year. 
In  this  case  study,  we  had  to  predict  the  actual  failures  based  on  MTBF  and  MRDB  data. 
In  reality,  under  the  SSB  method,  procurement  costs  would  only  be  incurred  when  a 
COTS  product  fails.  Under  the  LTB  method  we  are  procuring  COTS  products  in 
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advance  of  their  failure.  If  they  don’t  fail,  we’ve  bought  an  item  for  no  reason.  Finally, 
the  SSB  method  has  a  much  more  stable  funding  profile.  This  has  significant  impacts  to 
improving  the  planning  and  budgeting  aspects  of  the  program. 

One  final  thought  is  to  compare  all  six  scenarios.  Given  the  tremendous  cost 
associated  with  a  complete  technology  refresh,  we  will  exclude  this  alternative  in  the 
following  two  graphs.  This  allows  us  to  focus  on  the  five  remaining  support  scenarios. 
In  this  way  we  can  see  what  can  be  gained  by  initiating  a  particular  support  strategy  early 
in  the  acquisition  cycle. 


$7,000 

$6,000 

$5,000 

$4,000 

$3,000 

$2,000 

$1,000 

$0 

Total  Initial  Support  Cost 

2003 

□  LTB(1)  □  LTB  Only  bSSB(1)  □  SSB  Optimized  □  SSB  Only 

Chart  23:  Total  Initial  Support  Cost  (LTB(l),  LTB  Only,  SSB(l),  SSB  Optimized,  SSB  Only) 

From  this  we  can  see  that  the  greater  degrees  to  which  we  implement  the  SSB 
process  the  lower  the  initial  investment.  The  lower  initial  investment  translates  into 
lower  risk.  So  in  effect,  implementing  the  SSB  System  acts  a  risk  mitigation  tool. 
Considering  the  following  cost  profiles  further  emphasizes  this. 

The  following  graph  shows  the  annual  support  costs  for  the  remaining  years  out  to 
2012.  The  trend  lines  show  the  stability  in  funding  over  this  period. 
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Of  all  the  scenarios,  only  the  ‘ SSB  Only’  scenario  exhibits  a  stable  funding 
profile.  Recall  for  the  ‘ SSB(1 )’  and  ‘ SSB  Optimized’  scenarios,  we  had  to  include  the 
cost  for  a  partial  tech  refresh  for  those  nine  identified  COTS  products.  This  additional 
cost  skews  the  stability  for  these  two  scenarios.  Of  course,  after  the  first  few  years 
(2003-2006)  their  funding  profiles  become  more  consistent  from  one  year  to  the  next. 

D.  ANALYSIS  OF  RESULTS 

In  this  section  we  derive  usable,  decision-making  information  from  the  results  of 
the  previous  section.  The  results  will  be  summarized  and  evaluated  for  their  contribution 
to  the  business  objectives.  This  section  will  address  both  financial  metrics  as  well  as 
non-financial  implications. 

1.  Direct  Financial  Impacts 

The  financial  aspects  are  summarized  below  for  the  four  scenarios  we  defined  in 
the  previous  section. 


350 


Scenario 

First  Year 
Costs 

Total  All 
Years 

NPV  Total 
All  Years 

Consumed 

Inventory 

NPV 

Adjusted 

Total 

LTB(l) 

$5,924 

$9,639 

$8,651 

$701 

$9,352 

SSB(l) 

$3,440 

$8,415 

$7,333 

$701 

$8,034 

SSB 

Optimized 

$2,858 

$8,665 

$7,321 

$701 

$8,022 

LTB  Only 

$5,234 

$8,970 

$7,981 

$0 

$7,981 

+ — _ 

$0  „ 

—^$7,539 

Appendix  C  Table  8:  Total  Support  Costs 


The  above  table  demonstrates  the  potential  savings  in  the  first  year  as  well  as  the 

overall  costs  to  support  the  SSDS  program  over  the  defined  ten-year  period.  These 

values  are  taken  directly  from  the  cost  models  in  Enclosure  30. 

1)  When  the  SSB  process  was  implemented,  regardless  of  degree,  significant 
savings  were  realized.  See  column  NPV Adjusted  Total  in  the  above  table. 


2)  When  the  SSB  process  was  implemented,  the  initial  year  costs  were  reduced 
indirectly  proportional  to  the  degree  of  SSB  implementation.  See  column  First 
Year  Costs  in  the  above  table. 


Scenario 

First  Year 
Costs 

Total 

All  Years 

NPV  Total 
All  Years 

Consumed 

Inventory 

NPV 

Adjusted 

Total 

LTB(l) 

$5,924 

$7,069 

$6,871 

$701 

$7,571 

SSB(l) 

$3,059 

$6,854 

$6,025 

$701 

$6,726 

SSB 

Optimized 

$2,477 

$7,004 

$6,012 

$701 

$6,712 

LTB  Only 

$5,234 

$6,400 

$6,201 

$0 

$6,201 

_ J6,231 

Appendix  C  Table  9:  Procurement  Costs 


The  above  table  demonstrates  the  potential  procurement  savings  in  the  first  year 
as  well  as  the  overall  costs  to  support  the  SSDS  program  over  the  defined  ten-year  period. 
These  values  are  taken  directly  from  the  cost  models  in  Enclosure  30. 
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1)  When  the  SSB  process  was  implemented,  regardless  of  degree,  significant 
savings  were  realized.  See  column  NPV  Adjusted  Total  in  the  above  table.  The 
figure  for  SSB  Only  is  slightly  larger  than  for  LTB  Only.  The  reason  for  this  is 
because  the  SSB  process  requires  a  cost  to  purchase  Red  Parts  each  year,  the 
first  year  being  $534,01 1  and  a  total  for  all  years  of  $828,426.  The  LTB 
methods  make  the  assumption  that  they  can  purchase  all  the  required  items 
upfront  for  usage  throughout  the  ten-year  period  and  that  all  item  will  be 
consumed.  There  is  risk  involved  with  buying  too  many  or  not  enough  items. 

2)  When  the  SSB  process  was  implemented,  the  initial  year  costs  were  reduced 
indirectly  proportional  to  the  degree  of  SSB  implementation.  See  column  First 
Year  Costs  in  the  above  table. 

When  we  perform  standard  deviation  calculations  over  the  ten-year  period  we  get 


the  following. 


STD  DEV 

LTB(l) 

LTB  Only 

- -  ~~ 

All  Years 

1836 

1617 

/836 

627 

231 

100 

102 

(  55 

61 

-<) 

105 

108 

10 

7 

Appendix  C  Table  10:  Standard  Deviation  Procurement  Costs 


1)  When  the  SSB  process  is  implemented,  we  experience  a  more  stabilized 

funding  profile  for  procurement,  particularly  for  the  middle  eight  years.  See  the 
above  table. 

When  we  look  at  the  standard  deviation  for  the  total  support  costs  for  each 
scenario  we  get  the  following.  Remember,  for  the  LTB(l)  and  SSB(l)  scenarios  we  had 
to  take  into  account  a  redesign  effort  for  nine  COTS  items.  This  cost  is  incurred  early  in 


the  ten-year  period  and  affects  the  overall  stability  of  the  funding  profile. 


STD  DEV 

LTB(l) 

LTB  Only 

SSB(l) 

SSB 

Optimized 

SSB  Only 

2003-2012 

All  Years 

1896 

1597 

1322 

1208 

303 

2004-2012 
Excludes  Initial 
Year 

1068 

508 

1135 

1131 

111 

2004-2011 
Middle  years 

1056 

526 

1188 

1186 

16 

Appendix  C  Table  11:  Standard  Deviation  Total  Support  Costs 
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1)  When  SSB  is  implemented  early  enough  we  can  effectively  avoid  any  redesign 
costs  that  would  be  needed  due  to  obsolescence  during  the  ten-year  period  and 
therefore  expect  the  greatest  stability  in  the  funding  profile  over  the  ten-year 
period. 

The  percentage  of  overall  initial  costs  associated  with  each  scenario  is  given 

below. 


Initial  Costs  as  a  Percentage  of 
Total  Cost 


2003 


□  LTBOnly  nLTB(1)  bSSB(1)  □  SSB  Optimized  □  SSB  Only 


Chart  25:  Initial  Costs  as  a  Percentage  of  Total  Cost  (LTB(l),  LTB  Only,  SSB(l),  SSB  Optimized, 
SSB  Only) 

1)  When  the  SSB  process  was  implemented,  the  initial  cost  as  a  percentage  of  the 
total  cost  to  the  program  was  significantly  reduced  depending  on  the  degree  of 
implementation.  This  helps  to  reduce  the  risks  associated  with  making  large 
upfront  investments  as  the  costs  are  more  evenly  distributed  over  the  entire  ten 
years. 

2)  When  the  SSB  process  was  implemented,  the  costs  are  more  evenly  distributed 
over  the  ten-year  period  depending  on  the  degree  of  implementation.  This  is 
more  desirable  for  planning  and  budgetary  purposes. 

The  following  table  provides  the  costs  associated  with  having  to  redesign  those 
COTS  products  that  were  targeted  for  redesign  prior  to  SSB  implementation.  These 
items  were  determined  to  become  obsolete  prior  to  2003,  and  unsupportable  via 
traditional  support  mechanisms. 
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WBS  Element 

Total  ($K) 

Total 

7063 

Configuration  Management 

126 

Hardware/Software  Engineering 

1684 

Testing  And  Documentation 

944 

Procurement 

3866 

ILS  Planning  and  Management 

337 

Installation 

107 

Appendix  C  Table  12:  Total  Support  Costs  Required  for  Tech  Refresh 

1)  The  total  cost  that  could  have  been  potentially  avoided  if  the  SSB  process  had 
been  implemented  for  those  identified  COTS  products  is  approximately 
$7.063M. 

This  $7.063M  cost  is  considered  the  potential  Avoided  Costs  when  implementing 
the  SSB  process  during  SSDS  design.  The  optimal  SSB  implementation  point  being  the 
earliest  point  in  the  system  engineering  process. 

The  following  summaries  show  the  savings  for  procurement,  resources  and  the 


total  support  costs  between  the  two  most  practical  scenarios  (LTB(l)  and  SSB(l). 


LTB(l)  Procurement  Cost  (Typical  scenario) 

SSB(l)  Procurement  Cost  (Actual  SSB  Implementation) 

$6871 

$6025 

Procurement  Savings 

$846 

LTB(  1 )  Resource  Cost 

$1780 

SSB(l)  Resource  Cost 

$1308 

Cost  Savings 

$  472 

LTB(l)  Total  Support  Cost 

$8651 

SSB(l)  Total  Support  Cost 

$7333 

Cost  Savings 

$1318 

Appendix  C  Table  13:  Total  Support  Cost  Savings:  SSB(l)  versus  LTB(l) 


1)  When  the  SSB  process  was  implemented  significant  cost  savings  is  realized. 

The  following  data  illustrates  the  potential  savings  of  the  current  typical  support 
scenario  of  LTB  and  a  required  tech  refresh  of  nine  items  and  SSB  for  all  COTS  products 
upfront.  The  units  are  in  K  dollars. 
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LTB(l) 

$8651 

SSB  Only 

$7539 

Potential  Cost  Savings 

$1112 

Cost  Tech  Refresh  of  9  Items 

$7063 

Cost  to  SSB  the  9  Items 

$669 

Avoided  Cost  Savings 

$6394 

Total  Potential  Cost  +  Avoided  Cost 

$7506 

Appendix  C  Table  14:  Total  Savings:  Potential  Cost  +  Avoided  Cost 

1)  If  SSB  was  implemented  for  all  COTS  products  early  enough  we  can 
essentially  avoid  the  cost  associated  with  a  required  partial  tech  refresh. 


The  final  summary  of  data  looks  at  the  extreme  cases.  The  following  illustrates 
the  savings  between  implementing  SSB  early  in  the  acquisition  cycle  to  affect  all  COTS 


products  and  redesigning  all  COTS  products. 


Complete  Tech  Refresh 

$61089 

SSB  Only 

Jg  753Q 

Procurement  Savings 

C  $53550 

Appendix  C  Table  15:  Savings:  SSB  Only  versus  Complete  Tech  Refresh 


In  looking  at  the  SSB  portion  of  the  first  year  procurement  costs  for  each  scenario 


we  get  the  following  table. 


Support  Method 

Non  SSB  Costs 

SSB  Costs 

SSB%  of  Total 
Costs 

LTB(l) 

$5,924 

$  0 

0.0% 

LTB  Only 

$5,234 

$  0 

0.0% 

SSB(l) 

$2,097 

$  962 

31.4% 

SSB  Optimized 

$1,321 

$1,156 

46.7% 

SSB  Only 

$  103 

$1,243 

92.3% 

Table  13:  SSB  Portion  of  Total  Support  Cost 


1)  For  all  but  the  ‘ SSB  ’  Only  scenario  four,  the  majority  of  the  initial  procurement 
costs  are  associated  with  non-SSB  support  mechanisms. 

2)  The  greater  degree  of  SSB  implementation  the  lower  the  initial  investment  and 
thus  lower  program  risk. 

In  comparing  the  resource  models  for  the  traditional  and  actual  implementations 
we  notice  similar  orders  of  magnitude  for  total  costs. 
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WBS  Element 

Actual  ($K) 

Traditional  ($K) 

Total 

— ►  8415 

— ►  9639 

Configuration  Management 

0 

57 

Hardware/Software  Engineering 

0 

0 

Testing  and  Documentation 

0 

0 

Procurement 

10 

7069 

ILS  Planning  and  Management 

0 

2354 

Installation 

_ 

158 

Sunset  Supply  Costs 

C  8404 

- 

Appendix  C  Table  16:  Support  Cost  Comparison:  SSB(l)  -  Actual  versus  LTB(l)  Traditional 


The  SSB  infrastructure  absorbs  nearly  air  the  costs  for  supporting  COTS  products 
over  the  ten-year  period. 

1)  The  actual  scenario  provides  infrastructure  to  support  the  SSDS  program, 
resulting  in  greater  flexibility  and  manageability  for  the  PM. 

2)  Implementation  of  the  SSB  infrastructure  is  possible  at  the  same  or  lower  cost 
to  the  program  as  traditional  methods. 

5.  NON-FINANCIAL  IMPACTS 

Certain  non-financial  impacts  materialize  based  in  part  on  financial  consequences. 
In  order  to  successfully  evaluate  the  results  of  implementing  the  SSB  process  we  must 
look  at  these  non-financial  aspects  in  light  of  the  business  objectives.  But  first  we  must 
clearly  derive  such  impacts.  Since  no  clear  financial  metric  can  be  applied  to  these 
impacts  we  will  discuss  them  in  broad  terms  and  in  ways  that  can  be  observed  and 
verified.  The  approach  here  will  declare  a  financial  outcome  or  business  practice  of 
implementing  the  SSB  infrastructure,  and  explain  in  non-financial  terms  the  tangible 
impact. 

a.  Low  Initial  Expense 

By  reducing  the  upfront  costs  for  procuring  expected  spares,  the  SSB  process 
brings  improved  flexibility  to  planning  and  budgeting.  If  the  initial  costs  are  large  then 
the  PMO  is  forced  to  stay  the  course  for  the  entire  period  in  order  to  derive  the  maximum 
return  on  investment.  Changing  program  direction  during  the  ten-year  period  would  be 
difficult  to  argue  given  the  number  of  spare  COTS  products  that  would  become 
potentially  useless.  Under  the  SSB  infrastructure  much  of  the  initial  costs  are  still 
associated  with  non-SSB  support  mechanisms;  therefore,  these  costs  will  be  absorbed  in 
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the  event  the  program  did  not  make  use  of  the  assets  that  were  procured.  In  the  All  SSB 
scenario,  nearly  all,  about  92%,  of  the  upfront  costs  are  for  SSB  support.  The  benefits 
associated  with  this  cost  are  immediately  realized,  that  is  the  procured  COTS  items  are 
deployed  to  the  fleet  for  use  upon  purchase.  Furthermore,  in  the  event  that  performance 
requirements  change,  driving  a  change  in  system  design,  the  risks  are  greatly  reduced  if 
less  of  an  investment  was  made  for  spares  that  may  not  be  needed.  So  therefore  the  SSB 
process  effectively  reduces  the  risk  of  overspending  early  in  the  support  cycle. 

Derived  Benefits: 

•  Cost  Savings 

•  Flexibility 

•  Reduced  risk 

•  Stability 

b.  Stable  Funding  Profile 

The  SSB  process  spreads  the  procurement  costs  more  evenly  throughout  the  ten- 
year  period.  This  makes  efficient  use  of  funds  and  is  easier  to  budget  and  manage.  The 
yearly  costs  are  higher  under  the  SSB,  but  that’s  because  no  investment  in  spares  was 
made  the  first  year.  Nevertheless,  as  before,  the  costs  associated  with  these  years  are  for 
forecasted  replacements  on  an  as  need  basis.  The  costs  are  incurred  at  the  moment  a 
requisition  is  made  for  a  replacement  COTS  item.  The  benefit  is  immediately  realized. 
Furthermore,  by  procuring  COTS  replacement  products  only  on  demand  the  PM  makes 
better  use  of  funds.  Also,  continual  market  surveillance  is  practiced  throughout  the 
support  cycle  providing  real-time  data  in  terms  of  obsolescence  and  diminishing 
materials.  In  this  way  the  PM  is  better  equipped  to  make  effective  decisions  that  benefit 
the  overall  program.  This  environment  creates  a  flexible  process  that  by  taking  a 
proactive  posture  can  react  to  changes  in  material  availability. 

Derived  Benefits: 

•  Stability 

•  Efficient  use  of  funds 

•  Flexibility 

•  Risk  Mitigation 
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c.  The  Sunset  Supplier  Shares  Risk 

One  area  of  cost  savings  not  addressed  was  the  cost  to  the  Navy  for  stockage, 
storage  and  issue  of  COTS  spares  and  repair  parts.  These  are  costs  not  directly  borne  by 
the  SSDS  program.  But  in  addition  to  the  cost  savings  to  the  Navy  for  not  having  to 
house,  manage  and  transport  these  COTS  items,  the  Sunset  Supplier  now  assumes  the 
responsibility,  and  thus  risk,  of  facilitating  these  functions  and  recoup  the  value  added  by 
adjusting  the  product  purchase  price  by  5%  on  each  COTS  item  procured. 

Derived  Benefits: 

•  Risk  Mitigation  &  Management 

•  Shared  Risk 

•  Shared  responsibility 

•  Collaborative  environment 

d.  Extending  COTS  Supportability 

Recall  the  costs  derived  due  to  COTS  products  that  were  supported  by  OTHER. 
The  resource  model,  Enclosure  30  ( Resource_Cost_Model ,  worksheet  Partial  Tech 
Refresh),  demonstrated  the  costs  associated  with  having  to  redesign  before  the  end  of  the 
support  cycle.  This  figure  was  $7.063M.  The  point  here  is  that  by  implementing  the 
SSB  process  early  enough  in  the  program,  we  can  effectively  extend  supportability  for 
these  items.  And  in  fact  we  can  extend  the  reparability  of  these  items  by  identifying  and 
procuring  near-obsolete  components  (Red  Parts).  In  this  particular  case,  by  the  time  the 
SSB  infrastructure  was  in  place,  it  was  too  late  and  subsequently  cost  the  program  an 
additional  7  million  dollars.  The  planning  for  redesign  carries  certain  risks  as  well.  The 
DoD  will  almost  certainly  use  COTS  products  for  the  commercial  technology  advantages 
touched  on  earlier  in  this  document.  And  they  will  work  towards  specific  warfighter 
performance  requirements.  For  the  COTS  products  identified  in  Enclosure  30,  the  items 
were  detennined  to  be  obsolete  by  2005-6  timeframe.  Now  remember  that  there  is  a  2-3 
year  planning  period  and  additional  3-5  year  implementation  period  for  new  designs.  If 
the  period  of  concern  starts  in  2003,  the  COTS  products  could  become  unsupportable 
before  the  planning  phase  even  ends.  By  implementing  the  SSB  process  we  effectively 
avoid  this  situation  by  extending  supportability  of  the  COTS  products  so  that  warfighter 
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requirements  can  continue  to  be  met  while  plans  are  made  to  upgrade  the  system.  By 
stabilizing  the  system  baseline  this  way  we  mitigate  the  risks  of  not  being  able  to  support 
the  warfighter  to  acceptable  levels. 

Derived  Benefits: 

•  Extending  COTS  Supportability 

•  Extend  COTS  Reparability 

•  Cost  Savings/Cost  Avoidance 

•  Stabilize  System  Baseline 

•  Risk  Mitigation  &  Management 
e.  Initial  Investment 

Recall  that  the  initial  cost  for  setting  up  the  SSB  infrastructure  and  making  the 
initial  COTS  product  assessments  was  approximately  $380K  (taken  from  Enclosure 
(30)).  This  is  a  minor  investment  considering  that  the  realizable  return  is  substantial 
depending  on  how  early  in  the  acquisition  cycle  SSB  is  implemented.  For  example,  the 
cost  of  support  for  the  present  SSDS  before  SSB  was  considered  was  estimated  to  be 
$865  IK  plus  an  additional  partial  tech  refresh  cost  of  $6394K  (total  of  $15045).  The 
estimated  cost  of  implementing  SSB  early  enough  to  affect  all  COTS  products  was 
$7539K.  The  potential  savings  is  roughly  $7.5M.  That,  in  itself,  is  a  wonderful 
marketing  element,  however  there  is  also  another  point  to  made;  and  that  is  that  this  setup 
and  assessment  can  be  performed  for  any  program.  Thus,  the  SSB  process  is 
transportable  and  repeatable.  And  as  the  proliferation  of  COTS  products  increases 
throughout  the  military,  there  is  a  strong  likelihood  that  commonality  of  COTS  products 
across  weapon  systems  will  grow.  Having  a  SSB  process  that  maintains  and  continually 
updates  a  database  of  these  COTS  products  for  usage,  obsolescence,  and  diminishing 
materials  will  provide  a  tremendous  benefit  whose  value  will  grow  exponentially.  Thus, 
the  SSB  process  is  also  expandable.  This  initial  investment  is  made  within  the  DoD, 
tasking  Navy  resources  to  perform  supportability  assessments  and 
DMSMS/Obsolescence  Management.  The  reports  generated  become  government 
property  and  distributed  among  the  DoD  PMOs  as  well  as  commercial  support  entities 
(Sunset  Supplier).  Therefore  other  programs  can  leverage  the  data  and  the  relationships 
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from  the  SSB  infrastructure.  This  initial  investment  is  also  used  to  fund  the  government 
facilitating  activity  for  pursuing  and  coordinating  potential  OEM  and  Sunset  Suppliers. 


Derived  Benefits: 

•  Transportable,  repeatable  and  expandable. 

•  DMSMS/Obsolescence  reporting 

•  Collaborative  Environment 

•  Coordination 

6.  SUMMARY  OF  FINANCIAL  AND  NON-FINANCIAL  BENEFITS 


[  Summary  of  Benefits  j 

Financial 

Non-Financial 

•  Reduced  Procurement  Cost 

•  Lower  Upfront  Costs 

•  Significant  Cost  Avoidance 

•  Stabilized  Funding  Profile 

•  Overall  Cost  Savings  to  the 
Program 

•  Flexibility  -  Planning  & 
Budgeting 

•  Reduced  risk 

•  Stability  -Funding  Profile 

•  Efficient  use  of  funds 

•  Risk  Mitigation  &  Management 

•  Shared  Risk 

•  Shared  Responsibility 

•  Collaborative  Environment 

•  Extending  COTS  Supportability 

•  Extend  COTS  Reparability 

•  Stabilize  System  Baseline 

•  Transportable,  repeatable  and 
expandable. 

•  DMSMS/Obsolescence 
reporting 

•  Coordination 

Appendix  C  Table  17:  Summary  of  Benefits 
7.  ALIGNMENT  WITH  SSB  SPECIFIC  GOALS 


SSB  Specific  Goal 

Derived  Benefit 

Achieve  significant  and  quantifiable  cost 
savings  over  the  product  life  cycle. 

•  Reduced  Procurement  Cost 

•  Lower  Upfront  Costs 

•  Significant  Cost  Avoidance 

•  Stabilized  Funding  Profile 

•  Overall  LC  Cost  Savings  to  the 
Program 
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SSB  Specific  Goal 

Derived  Benefit 

To  be  able  to  identify,  quantify,  and 
mitigate  supportability  risk  to  programs. 

•  DMSMS/Obsolescence 
reporting 

•  Reduced  risk 

•  Risk  Mitigation  &  Management 

•  Shared  Risk 

Extend  the  life  cycle  and  supportability  of 
COTS. 

•  Extending  COTS  Supportability 

•  Extending  COTS  Reparability 

Provide  infrastructure  to  support  existing 
platform/combat  systems  in  support  of  the 
PMO. 

•  Transportable,  repeatable  and 
expandable. 

•  Coordination 

•  Collaborative  Environment 

By  virtue  of  SSB  implementation  and  the  benefits 
documented  within  this  section,  ail  infrastructure  is 
obviously  in  place  to  support  existing  weapon 
systems. 

A  reliable,  affordable,  repeatable,  and 
expandable  process  that  meets  the 
customer’s  performance  expectations  (e.g., 
accessible,  transportable,  maintainable, 
predictable). 

•  DMSMS/Obsolescence 
reporting 

•  Transportable,  repeatable  and 
expandable. 

•  Stabilize  System  Baseline 

Institutionalize  methods  for  proactive 
management  of  COTS  including  DMSMS 
issues. 

•  DMSMS/Obsolescence 
reporting 

•  Collaborative  Environment 

A  system  that  leverages  Navy  and 
commercial  supportability  assets  and 
provides  a  networked  solution. 

•  Collaborative  Environment 

•  Shared  Responsibility 

•  Shared  Risk 

•  Coordination 

Leverage  across  government  programs  with 
extended  applicability  through  contract 
strategies,  methodologies,  and  incentives  to 
entice  commercial  industry  participation. 

•  Flexibility  -  Planning  & 
Budgeting 

•  Transportable,  repeatable  and 
expandable 

•  Collaborative  Environment 

Forecast  budget  requirements  in  support  of 
the  programs/war  fighter/consumer 

•  Flexibility  -  Planning  & 
Budgeting 

•  Efficient  use  of  funds 

•  DMSMS/Obsolescence 
reporting 

Improve  schedule  flexibility  and  support 
options  of  system  upgrades  or  new 
development  initiatives. 

•  Flexibility  -  Planning  & 
Budgeting 

•  Extending  COTS  Supportability 
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SSB  Specific  Goal 

Derived  Benefit 

•  Stabilize  System  Baseline 

Appendix  C  Table  18:  Alignment  of  Benefits  with  SSB  Specific  Goals 


8.  CONTRIBUTIONS  TO  BUSINESS  OBJECTIVES 

a.  Financial  and  Business  Performance 

The  implementation  of  the  SSB  process  to  the  SSDS  program  has  had  positive 
impacts  to  both  the  financial  and  business  performance  requirements.  The  SSB  process 
essentially  provides  an  architecture  that  specifically  addresses  the  issue  of  obsolescence, 
diminishing  manufacturing  sources,  and  material  shortages.  In  this  way  the  risk  to  the 
program  is  significantly  reduced.  The  architecture  provides  effective  coordination  and 
networking  leading  to  tremendous  cost  savings  as  well  as  the  ability  to  ensure  long-term 
supportability  for  COTS  products.  From  a  financial  perspective,  the  SSB  process  allows 
for  the  opportunity  to  significantly  reduce  the  upfront  costs  and  stabilize  the  funding 
profile  over  the  period  of  support  leading  to  a  much  more  efficient  use  of  funds.  This  is 
in  addition  to  sizeable  cost  savings  and  avoidance.  From  a  business  perspective,  the 
overall  awareness  of  obsolescence  and  material  shortages  gives  the  PM  more  information 
for  making  effective  decisions.  Furthermore,  the  risk  mitigation  aspects  of  the  SSB 
process  come  from  establishing  a  collaborative  environment  where  the  responsibilities 
and  risks  are  shared  between  the  commercial  and  government  activities.  Out  of  this 
environment  come  positive  business  impacts  in  tenns  supportability,  program  planning, 
program  risk  and  life  cycle  cost  management. 

b.  Strategic  Positioning  and  Ownership 

The  SSB  infrastructure  was  implemented  into  the  SSDS  program.  The  overall 
environment  is  one  of  collaboration,  coordination  and  trust.  The  functions  are 
coordinated  across  a  network  of  commercial  and  government  activities.  The  expertise 
from  both  the  private  and  public  sectors  is  shared  across  this  network.  This  situation 
nurtures  long-term  relationships  between  the  commercial  entities  and  the  DoD.  These 
relationships  are  consistent  with  present  DoD  and  industry  partnering  initiatives.  This 
and  the  fact  that  the  SSB  process  has  provided  tremendous  cost  savings  to  the  SSDS 
program  only  strengthens  the  strategic  position  of  the  SSB  concept  within  the  set  of 
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support  alternative  solutions  presently  available  to  the  PMO.  Furthermore,  the  mere  fact 
that  the  PMO  has  discretion  and  authority  to  create  an  SSB  environment  illustrates  the 
control  and  ownership  the  PMO  has  in  face  of  COTS  product  proliferation.  Remember, 
the  COTS  initiative  essentially  reduces  the  control  the  DoD  has  historically  had  over 
system  design  and  support.  The  SSB  process  allows  the  PMO  to  regain  some  control  in 
that  it  extends  supportability  and  maintains  key  technologies  for  stabilizing  the  system 
baseline. 

c.  Operations  and  Functions 

Reviewing  the  benefits  that  are  derived  by  implementing  the  SSB  process,  we 
immediately  realize  the  positive  effect  it  has  on  extending  COTS  product  supportability 
for  the  SSDS  program.  Recall,  that  commercial  product  life  cycles  are  typically  18- 
months  to  2-years,  whereas  DoD  planning  and  implementation  easily  exceeds  5  years.  In 
this  case  the  SSB  process  allowed  the  PMO  to  postpone  likely  redesigns  that  result  from 
obsolescence.  By  extending  supportability,  the  SSB  processes  gives  the  PMO  the 
opportunity  to  better  forecast  and  react  to  changes  in  warfighter  requirements  as  well  as 
in  the  market.  Overall  management  of  the  program  is  made  more  efficient  given  the 
extended  timeframe  for  assessing  technology  trends  and  evolving  warfighter 
requirements.  By  extending  COTS  product  supportability,  the  PMO  can  now  align 
technology  refresh  cycles  with  product  end-of-production  dates.  In  this  case  we  are 
talking  about  the  extended  production  of  a  specific  COTS  product  by  the  Sunset  Supplier. 
At  the  same  time  we  can  essentially  compress  the  timeframe  for  delivering  support  to  the 
warfighter.  Sunset  Suppliers  take  on  the  responsibility  of  stockage,  storage,  and  issue  of 
COTS  replacement  and  repair  parts.  Improved  delivery  to  the  warfighter  is  expected 
since  the  Sunset  Supplier  is  contractually  responsible  for  specific  performance  metrics. 

d.  Product  and  Services 

With  the  implementation  of  the  SSB  process,  key  enabling  technologies  are 
retained  through  extended  supportability  over  a  defined  period  of  time.  The  net  result  is  a 
stabilized  system  performance  baseline  with  an  overall  improvement  in  terms  of  product 
and  service.  The  SSB  process  allowed  the  PM  to  match  the  COTS  product  update  cycles 
with  the  program’s  technical  roadmap  or  refresh  effort.  Furthermore,  as  a  product,  the 
SSB  infrastructure  becomes  part  of  a  toolset  that  provides  obsolescence  indicators  and 
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e. 


reports  as  well  as  the  ability  to  mitigate  maintenance  and  supportability  issues  at  the 
assembly  level.  This  support  strategy  can  now  include  a  mechanism  for  establishing  and 
managing  the  information  obtained  from  the  assessment  and  reporting  activities,  thus 
empowering  the  PM  with  the  knowledge  necessary  to  deliver  an  improved  customer 
service.  In  the  long  run  the  system  integrity  is  maintained,  which  has  several 
implications  in  terms  of  integrated  logistical  support  (i.e.  training,  manuals,  configuration 
control,  etc..) 

Image 

The  financial  and  non-financial  benefits  derived  and  identified  within  this 
document  prove  the  viability,  effectiveness  and  value  of  the  SSB  concept  as  alternative  to 
conventional  support  mechanisms.  Not  necessarily  as  a  replacement  for  these  traditional 
methods  but  as  another  option.  The  SSB  process  does  not  intend  to  extend  supportability 
for  the  sake  of  retaining  old  technology,  but  rather  to  stabilize  the  system  performance 
baseline  for  periods  that  can  be  aligned  with  typical  DoD  acquisition  cycles.  It  offers  an 
opportunity  for  the  PMO  to  consider  redesigns  based  on  perfonnance  enhancements  in 
response  to  evolving  warfighter  requirements  rather  than  redesigns  due  to  obsolescence. 
This  mere  fact  makes  this  an  attractive  scenario  from  a  PM’s  perspective  for  improving 
life  cycle  management.  And  in  conjunction  with  the  significant  cost  savings  the  overall 
appeal  of  the  SSB  concept  should  make  it  the  alternative  of  choice  for  PMs  seeking  to 
optimize  their  support  strategy. 
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XII.  CONCLUSION 


A.  SUMMARY 

The  overall  acquisition  of  military  weapon  systems  is  a  challenging  endeavor  to 
say  the  least.  One  thing  that  has  been  reported,  and  confirmed  in  this  business  case 
analysis,  is  that  procurement  costs  make  up  more  than  half  of  the  acquisition  costs.  In 
fact,  the  procurement  costs  incurred  after  a  system  has  been  fielded  still  accounts  for  the 
majority  of  the  life  cycle  costs.  This  scenario  has  lead  DoD  to  begin  leveraging 
commercial  standards,  products  and  practices  in  an  attempt  to  lower  risk  and  life  cycle 
costs.  The  use  of  COTS  products  has  made  great  strides  to  reducing  life  cycle  cost  while 
transferring  state-of-the-art  technologies  to  the  warfighter.  However,  these  gains  have 
come  with  their  own  set  of  problems.  Given  the  mission  criticality  and  software¬ 
intensive  architectures  of  present  weapon  systems,  slight  changes  in  COTS  products  are 
simply  unacceptable.  Minor  changes  to  a  piece  of  COTS  hardware  can  have  serious 
implications  to  readiness  and  program  costs,  given  their  software  intensive  nature.  It 
typically  takes  a  significant  effort,  in  tenns  of  time  and  money,  to  develop,  test  and 
deploy  upgraded  changes.  To  further,  complicate  the  issue,  these  weapon  systems  are 
developed  and  deployed  in  small  quantities  making  them  unattractive  for  typical 
commercial  business  interest.  The  uniqueness  of  these  systems  makes  them  difficult  to 
support  affordably.  And  given  that  commercial  technology  refresh  cycles  are  around  18- 
24  months  where  the  DoD  can  barely  hope  to  refresh  every  5-7  years,  there  is  little 
incentive  for  major  equipment  manufacturers  to  continue  production  of  a  product  that  no 
longer  fulfills  their  business  objectives  just  for  the  sake  of  accommodating  the  military, 
which  makes  up  less  than  0.4%  of  the  market.  There  is  really  only  one  of  two  ways  to 
handle  this  dilemma.  Either  accelerate  the  acquisition  phase,  which  is  highly  unlikely 
given  the  conservative  DoD  acquisition  approach,  or  extend  the  supportability  of  the 
COTS  products.  Additionally,  as  the  commercial  content  within  military  systems 
increase,  the  issue  of  COTS  product  supportability  is  complicated  by  orders  of 
magnitude.  Consider  for  a  moment  the  eventual  increase  in  technology  refreshes  needed 
across  the  DoD/Navy  program  spectrum  as  a  result  of  the  tremendous  proliferation  of 
COTS  in  military  applications.  This  increase  makes  the  issue  of  COTS  supportability  a 
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major  concern  during  acquisition  and  support  strategy  development.  For  program 
planning  and  budgeting  purposes  a  mechanism  is  needed  to  effectively  assess  the  COTS 
product  supportability  position  for  a  particular  program.  To  this  end,  the  SSB  concept 
provides  a  support  recommendation  process  for  each  COTS  product  in  the  weapon 
system  under  analysis.  This  approach  assists  the  Program  Manager  (PM)  in  making 
decisions  that  will  impact  life  cycle  costs  of  the  weapon  system  while  meeting  technical 
design  requirements.  And  from  a  planning  and  budgeting  perspective  it  provides  higher 
confidence  in  future  program  cost  predictions.  The  output  of  the  SSB  process  helps  PMs 
map  proposed  technology  updates  to  system  deployment,  operation  and  support  plans. 

B.  INTERPRETATION  OF  RESULTS 

The  results  presented  in  of  this  document  clearly  illustrate  that  the  SSB 
implementation  has  the  potential  to  offer  significant  cost  savings  to  the  SSDS  MKI 
program  in  terms  of  total  support.  The  savings  come  from  many  areas  depending  on  the 
present  state  of  the  program.  For  the  SSDS  program  certain  COTS  products  have  already 
been  slated  for  specific  support  methods.  These  include  redesign,  reclamation,  spares 
utilization,  maintenance  contracts  and  bridge  buys.  For  those  items  designated  as  a 
candidate  for  bridge  buys,  the  SCWG  considered  implementing  the  SSB  process  as  a 
support  solution  alternative.  Cost  models  were  generated  for  comparison  purposes  in 
order  to  fully  understand  the  impacts.  Three  main  scenarios  considered  to  be  the  most 
practical,  were  analyzed  in  terms  of  resource  and  procurement  costs.  In  an  effort  to  fully 
evaluate  the  SSB  implementation  three  additional  scenarios  were  generated.  These 
scenarios  are  impractical  at  this  stage  in  the  SSDS  program  but  could  be  viable 
alternatives  given  the  right  circumstances  such  as  early  in  the  acquisition  cycle. 
Nevertheless,  the  results  not  only  reflect  an  overall  cost  savings  for  the  ten-year  analysis 
period,  they  also  provided  further  insight  to  other  desirable  benefits.  In  particular,  risk 
mitigation  and  management  was  enhanced  for  the  PM.  The  SSB  method  had  an 
extremely  low  initial  investment  as  well  as  a  profoundly  stable  funding  profile  over  the 
ten-year  period.  The  low  initial  cost  translated  into  less  of  upfront  buy-in.  The  more 
money  that  is  invested  upfront,  the  more  you  are  locked  into  a  situation  in  order  to  derive 
the  greatest  return  on  those  initial  investments.  For  example,  let  us  say  that  you  purchase 
a  million  dollars  worth  of  spares  in  the  first  year  in  an  effort  to  support  a  particular 
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product  over  ten  years.  After  the  first  two  years  you  use  up  $200K  of  the  spares  when 
you  are  presented  with  an  opportunity  to  improve  product  support,  reduce  costs  and/or 
enhance  system  capabilities.  You  still  have  $800K  invested  in  spares.  In  this  case  you 
are  unlikely  to  take  advantage  of  this  opportunity.  Subsequently,  low  initial  cost  reduces 
the  risk  of  staying  the  course  and  fully  optimizing  program  attributes.  Furthermore,  in 
the  situation  where  you  have  made  significant  investment  in  spares  upfront,  you  are 
calculating  this  amount  based  on  a  forecast  of  failures  for  a  particular  item.  There  are 
two  risks  associated  with  this.  First,  investing  too  much  means  making  purchases  in 
spares  that  will  never  be  used.  Secondly,  buying  too  little,  runs  the  risk  of  not  being  able 
to  support  the  weapon  system  for  the  prescribed  period  of  support.  Along  with  the  low 
initial  costs,  the  SSB  method  allows  for  even  expenditures  of  the  remaining  funds.  To 
whatever  degree  the  SSB  was  implemented,  the  resulting  funding  profile  was  very  stable. 
This  stability  is  important  to  the  planning  and  budgeting  process.  Effective  planning  and 
budgeting  is  essentially  a  process  in  risk  mitigation,  and  anything  we  can  do  to  help  the 
planning  and  budgeting  process  helps  us  to  reduce  risk.  Also,  remember  the  very  nature 
of  the  SSB  infrastructure  is  a  collaborative  venture  in  which  responsibility  and  thus  risk  is 
shared  between  the  commercial  and  government  entities,  a  further  step  in  risk  reduction. 
Furthermore,  by  stabilizing  the  funding  profile  we  can  make  efficient  use  of  funds,  which 
is  a  recurring  mandate  throughout  government  acquisition  directives.  The  effects  of  SSB 
implementation  have  clear  financial  impacts,  which  are  aligned  with  Federal  and  DoD 
initiatives,  regulations  and  guidelines. 

The  financial  aspects  of  SSB  implementation  are  not  enough  to  conclude  it  as  a 
viable  support  solution  alternative.  Just  because  we  can  save  money,  we  have  to  ensure 
that  it  meets  the  requirements  of  the  program  and  ultimately  the  warfighter  as  well.  The 
SSB  process  extends  the  supportability  and  reparability  of  COTS  products.  By 
establishing  arrangements  between  Navy  Field  Activities/Resources,  the  OEMs  and  third 
party  small  businesses  (Sunset  Suppliers),  we  can  provide  insurance  to  the  Program 
Management  Office  (PMO)  that  a  particular  COTS  product  will  be  sustained  for  a 
defined  period  of  time.  In  fact,  delivery  of  the  replacement  spare  is  initiated  at  the  time 
of  failure  in  the  fleet.  The  COTS  item  is  purchased  on  demand  rather  than  upfront,  which 
is  based  on  failure  rate  data.  If  ten  items  fail  over  ten  years,  you  will  only  purchase  ten 
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replacement  items.  This  approach  again  is  flexible  and  provides  a  mechanism  for 
improving  the  planning  and  budgeting  for  the  next  tech  refresh  point.  The  extension  of 
support  stabilizes  the  system  baseline  so  that  a  more  focused  approach  is  given  to 
planning  for  future  product  or  system  redesign  efforts.  By  stabilizing  the  system  baseline 
for  a  defined  period  of  time,  we  again  reduce  risk  to  COTS  obsolescence  during  this 
period.  In  fact,  the  very  SSB  infrastructure  facilitates  effective  obsolescence  and  material 
shortage  assessment  and  reporting.  This  assessment  capability  is  a  coordinated  effort 
across  the  SSB  infrastructure.  As  the  SSB  is  implemented  on  more  programs 
membership  in  the  SSB  process  grows  allowing  greater  access  to  programs  Navy-wide. 
In  effect,  the  data  collected  in  one  program  is  likely  valuable  to  other  programs  given  the 
growing  proliferation  of  COTS  products  in  military  applications.  Therefore  we  visualize 
a  process  that  is  transportable,  repeatable  and  expandable  for  all  DoD/Navy  programs. 

C.  IMPACT  TO  ACQUISITION  STRATEGY 

This  Business  Case  Analysis  has  demonstrated  that  the  SSB  infrastructure  is  an 
affordable  approach  for  mitigating  program  supportability  risk.  The  collaborative  nature 
of  the  SSB  process  leverages  the  various  areas  of  high  perfonnance  and  ability  residing  in 
the  government,  big  business  and  the  small  businesses.  The  risks  are  quantifiable  and 
shared  across  the  infrastructure.  The  SSB  process  was  conceived  for  and  therefore 
sensitive  to  the  supportability  of  fielded  COTS  products  as  defined  by  the  warfighter.  As 
an  acquisition  strategy  it  extends  the  life  cycle  and  supportability  of  COTS  and  ensures 
late-life  cycle  supply  support.  The  SSB  process  essentially  pennits  the  DoD  to  be 
successful  in  leveraging  commercial  developments  with  appropriate  economies  of  scale 
in  order  to  reach  its  military  performance  goals  while  offsetting  the  problem  of  DMSMS. 

The  SSB  infrastructure  directly  supports  existing  combat/weapon  systems.  In  this 
way  it  provides  the  PMO  an  additional  support  solution  alternative.  This  alternative  can 
be  implemented  early  in  the  acquisition  process  to  demonstrate  the  value  and  viability  of 
COTS  product  usage.  The  SSB  process  can  also  provide  insight  to  the  supportability  of 
selected  COTS  products  early  enough  in  the  acquisition  process  to  significantly  reduce 
program  risk  related  to  COTS  and  life  cycle  management.  Additionally,  when  applied  to 
various  DoD/Navy  programs,  component  commonality  could  lead  to  a  flexible,  integrated 
logistical  support  approach.  This  scenario  would  likely  have  a  ripple  effect  that 
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incentivizes  the  commercial  industry  to  develop  long-tenn  relationships  with  the 
respective  PMOs. 

The  essence  of  the  SSB  process  lies  in  its  ability  to  detect  potential  supportability 
problems.  And  by  extending  the  supportability,  it  provides  sufficient  time  for  analysis  of 
alternatives  and  solutions  in  the  decision-making  processes.  Furthermore,  accurate 
assessment  of  COTS  supportability  can  be  accomplished  at  any  level  (subsystem, 
equipment,  component,  or  piece  part).  This  approach  not  only  extends  supportability  but 
reparability  as  well.  The  SSB  approach  is  to  procure  assemblies  when  the  customer 
requires  them.  To  this  end,  the  SSB  process  is  committed  to  continual  assessment  over 
the  entire  COTS  product  life  cycle.  Again,  this  approach  breeds  a  more  informed 
decision-making  process  translating  to  improved  support  performance  and  lower  life 
cycle  costs. 

Overall,  the  SSB  process  becomes  an  additional  and  likely  the  preferred  support 
solution  alternative  for  PMs  who  will  welcome  the  schedule  flexibility  provided  by  the 
SSB  process.  The  flexibility  comes  from  the  fact  that  the  SSB  infrastructure  can  tailor 
the  support  options  in  terms  of  functions  and  expectations  demanded  by  the  warfighter. 
These  functions  include  immediate  supportability  and  fast,  reliable  and  direct  delivery  to 
the  warfighter.  The  COTS  product  supportability  assessments  are  critical  to  effective 
SSB  implementation  and  therefore  a  great  deal  of  emphasis  is  placed  on  the  collection, 
maintenance  and  dissemination  of  the  information  and  knowledge  derived.  In  this  way 
the  SSB  process  is  definable  and  repeatable.  In  the  end,  the  SSB  provides  the  PM  with 
an  independent  utility  for  implementing  COTS  products  and  has  minimal  or  no  impact  on 
system  operational  performance.  Once  implemented,  the  SSB  is  an  affordable, 
expandable,  repeatable  and  reliable  process  that  will  meet  the  users  performance 
expectations.  It  provides  the  best  of  both  worlds.  It  leverages  the  inherently 
governmental  functions  of  the  Navy  supply  process  and  coordinates  with  commercial 
supportability  assets  through  a  thoroughly  meshed  and  maintainable  communication 
network  solution. 
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D.  RECOMMENDATION 


DoD  has  recognized  that  product  support  solutions  can  be  more  effectively 
designed  and  implemented  if  the  acquisition  and  logistics  communities  work  in 
partnership.  Within  the  SSB  infrastructure  integrated  acquisition  and  logistics  functions 
conduct  supportability  analysis  as  an  integral  element  of  the  systems  engineering  process. 
This  process  (SSB)  should  occur  at  the  beginning  of  program  initiation  to  ensure 
designed  in  reliability  and  maintainability  throughout  the  program  life  cycle.  This  will 
also  ensure  that  the  system  performance  baseline  remains  unchanged  therefore  continuing 
to  meet  the  warfighter's  supportability  requirements.  Although  applicable  at  any  phase  of 
the  acquisition  cycle,  it  is  critical  to  consider  the  SSB  implementation  in  the  earliest 
possible  stage  to  gain  maximum  benefit.  Consider  the  SSB  Only  support  scenario.  This 
scenario  essentially  employs  the  SSB  method  for  all  COTS  products.  The  SSB  Only 
method  illustrates  a  situation  where  SSB  was  implemented  prior  to  other  support  method 
choices  and  subsequent  commitments.  In  this  case  we  saw  the  greatest  stability  in  the 
funding  profile  and  the  lowest  initial  investment  amount.  Together  they  result  in  the 
lowest  risk  to  the  program  while  providing  more  flexibility  and  sustainment  capability. 

The  SSB  process  should  be  a  continuous  process.  COTS  product  supportability 
assessments  should  be  repeated  frequently  throughout  the  acquisition  cycle.  This 
approach  not  only  keeps  the  data  stored  on  COTS  products  fresh,  but  also  allows  for 
some  maturation  of  the  process.  The  plan  is  to  effect  a  Continuous  Measurable 
Improvement  environment  that  will  ensure  that  the  most  cost-effective  methods  of 
support  are  being  considered  and  subsequently  offered  to  the  PM. 

The  PM  is  expected  per  DoDD  5000  to  use  the  most  effective  source  of  support 
that  optimizes  performance  and  life  cycle  cost,  consistent  with  military  and  statutory 
requirements.  The  source  of  support  may  be  Organic  or  commercial,  but  its  primary 
focus  is  to  optimize  customer  support,  achieve  maximum  weapon  system  availability  at 
the  lowest  Total  Ownership  Cost.  At  their  disposal,  the  PM  has  a  set  of  support  methods 
that  can  be  used  to  achieve  this  objective,  the  SSB  process,  as  proven  in  this  BCA  to  be  a 
viable  and  effective  support  method,  should  be  included  as  an  additional  support  solution 
alternative  in  this  set. 
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ABSTRACT 


This  Marketing  Plan  is  one  of  the  four  foundational  documents  created  to 
establish  the  Sunset  Supply  Base  (SSB)  system  as  a  Commercial  off  the  Shelf  (COTS) 
supportability  alternative  for  Navy  fielded  systems  containing  COTS  products.  The  plan 
analyzes  the  environments  (external,  internal,  customer)  in  which  the  marketing  functions 
will  be  operating  in.  The  SSB  system  is  evaluated  for  its  attributes,  both  positives  and 
negatives  through  a  “SWOT”  (Strengths,  Weaknesses,  Opportunities,  Threats)  analysis. 
Each  of  these  characteristics  is  then  matched  to  a  marketing  strategy  to  improve  the 
system’s  marketability.  Two  goals  are  set:  A)  capture  20%  of  market  share  (72  Navy 
programs  or  80  man-yr  per  year  effort),  B)  Establish  an  Image  for  the  SSB  system  as  the 
alternative  of  choice  for  COTS  supportability  that  enables  cost  effective  Technology 
Insertion  in  fielded  Navy  systems.  Based  on  a  defined  Target  Market,  a  Marketing  Mix 
is  defined  that  identifies  a  series  of  marketing  actions  to  achieve  a  competitive  advantage 
for  the  SSB  system  in  maximizing  market  penetration.  This  Marketing  Plan  is  an  integral 
part  of  overall  System  Engineering  approach  used  to  develop  the  SSB  system  whereby 
the  implementation  of  this  plan  is  contained  within  the  system  implementation  process. 


377 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


378 


TABLE  OF  CONTENTS 


I.  EXECUTIVE  SUMMARY . 391 

II.  ENVIRONMENTAL  ANALYSIS . 393 

A.  THE  EXTERNAL  ENVIRONMENT . 393 

1 .  Competitive  Forces: . 393 

B.  COMPETITION  CATEGORIES . 393 

1 .  Resource  Competition: . 393 

2.  Territorial  Competition: . 394 

3 .  Contractual  Competition: . 394 

4.  Functional  Competition: . 394 

III.  THE  MARKET  PLACE  &  THE  PLAYERS . 397 

A.  THE  MARKETS: . 397 

1.  The  Players: . 399 

2.  Market  Place  Size: . 403 

B .  ECONOMIC  GROWTH  AND  STABILITY: . 403 

C.  POLITICAL,  LEGAL,  AND  REGULATORY  TRENDS . 404 

D.  PERFORMANCE  BASED  LOGISTICS  DEFINITIONS . 405 

IV.  THE  PERFORMANCE  BASED  CONTRACTING  ENVIRONMENT : . 413 

A.  THE  FOUNDATIONAL  PERFORMANCE  BASED  CONTRACTING 

DOCUMENTATION: . 413 

B .  RESPONSIBILITY  OF  THE  CONTRACTOR  VERSUS  THAT  OF  THE 

GOVERNMENT: . 413 

C.  THE  CONTRACTING  ENVIRONMENT: . 417 

1.  Excerpts  DoD  5000.1 . 417 

2.  Summary: . 420 

D.  PERFORMANCE  BASED  CONTRACTING  IMPLEMENTATION 

GUIDANCE  DOCUMENTATION: . 421 

1.  Excerpts . 421 

2.  Conclusion:  The  Performance  Based  Contracting  Environment: 424 

V.  THE  CUSTOMER  ENVIRONMENT . 427 

A.  WHO  ARE  OUR  CURRENT  AND  POTENTIAL  CUSTOMERS? . 427 

B.  WHAT  DO  OUR  CUSTOMERS  DO  WITH  OUR  PRODUCTS? . 428 

C.  WHERE  DO  OUR  CUSTOMERS  PURCHASE  OUR  PRODUCTS? ..  428 


379 


D.  WHEN  DO  OUR  CUSTOMERS  PURCHASE  OUR  PRODUCTS?  ....  428 

E.  WHY  (AND  HOW)  DO  OUR  CUSTOMERS  SELECT  OUR 

PRODUCTS? . 429 

F.  WHY  DO  POTENTIAL  CUSTOMERS  NOT  PURCHASE  OUR 

PRODUCTS? . 429 

VI.  INTERNAL  (ORGANIZATIONAL)  ENVIRONMENT . 43 1 

A.  REVIEW  OF  THE  MISSION . 43 1 

B.  REVIEW  OF  MARKETING  GOALS,  OBJECTIVES,  AND 

PERFORMANCE . 431 

C.  REVIEW  OF  CURRENT  AND  ANTICIPATED  RESOURCES . 434 

D.  REVIEW  OF  CURRENT  AND  ANTICIPATED  CULTURAL  AND 

STRUCTURAL  ISSUES: . 436 

VII.  SWOT  ANALYSIS  FOR  THE  SSB  SYSTEM . 441 

A.  STRENGTHS . 441 

B.  WEAKNESSES . 445 

C.  OPPORTUNITIES . 448 

D.  THREATS . 454 

E.  SWOT  MATCHING,  CONVERTING,  MINIMIZING,  AND  AVOIDING 

STRATEGIES: . 459 

VIII.  MARKETING  GOALS  AND  OBJECTIVES . 465 

A.  MARKETING  GOAL  A: . 465 

B.  MARKETING  GOAL  B: . 468 

IX.  MARKETING  STRATEGIES . 47 1 

A.  SEGMENTATION  &  DIFFERENTIATION . 471 

B .  TARGETING  &  POSITIONING . 473 

1 .  Resolution  Type  &  Positioning  Justification . 473 

C.  TARGET  MARKETS . 479 

D.  KEY  CUSTOMER  AND  COMPETITOR  REACTIONS . 480 

X.  MARKETING  IMPLEMENTATION . 481 

A.  STRUCTURAL  ISSUES . 48 1 

B.  MARKETING  MIX . 482 

1 .  Promotion  Plan  for  Group  1 ,  Decision  Makers . 490 

2.  Promotion  Plan  for  Group  2,  GateKeepers  /  Middlemen  / 

Intermediaries . 497 


380 


3.  Promotion  Plan  for  Group  3,  Using  Community . 499 

XI.  LIST  OF  REFERENCES . 503 


381 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


382 


LIST  OF  FIGURES 


Appendix  D  Figure  1:  Year  2001  Semiconductor  Usage . 398 

Appendix  D  Figure  2:  Declining  Military  Presence . 399 

Appendix  D  Figure  3:  System  Life  Cycle  Extensions . 404 

Appendix  D  Figure  4:  Perfonnance  based  Contract  Scenarios . 409 

Appendix  D  Figure  5:  Positioning  &  Differentiation  of  Support  Alternatives . 473 

Appendix  D  Figure  6:  Implementation  Process . 485 

Appendix  D  Figure  7:  17  Step  Implementation  Process . 485 

Appendix  D  Figure  8:  Positioning  &  Differentiation  of  Support  Alternatives . 491 

Appendix  D  Figure  9:  Comparison  of  Funding  Profiles . 492 


383 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


384 


LIST  OF  TABLES 


Appendix  D  Table  1:  Illustrates  the  various  PBL  categories  and  their  associated  attributes 

. 405 

Appendix  D  Table  2:  SWOT  Matrix . 458 

Appendix  D  Table  3:  Percentage  COTS  of  some  Navy  systems . 466 

Appendix  D  Table  4:  Target  Market . 467 

Appendix  D  Table  5:  Alternatives  Cost  Matrix  [16)  DMEA] . 471 

Appendix  D  Table  6:  Positioning  and  Differentiation  Table . 472 


385 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


386 


LIST  OF  ACRONYMS  AND  ABBREVIATIONS 


17  Steps 

SSB  System  Implementation  Process 

2  yr/board 

Two  years  per  board,  reflects  necessary  design  and 
development  time. 

$ 

Low  life  cycle  cost 

$$ 

Mid  Range  life  cycle  cost 

$$$$ 

Most  expesive  life  cycle  cost 

$K 

Cost  represented  in  thousands  of  dollars 

AIDA 

Attention,  interest,  desire,  action  -  marketing  action  model 

AN/ASQ-20X 

Designator  for  Sonar  Mine  Detecting  Set  developed  for  the 
Navy  under  the  program  management  code  PMS-210 

AR 

Acquisition  Reform 

ASN 

Assistant  to  the  Secretary  of  the  Navy 

BCA 

Business  Case  Analysis 

BOM 

Bill  of  Material 

CAGE 

Contractor  and  Government  Entity,  manufacturers  unique 
identifier  number. 

CLS 

Contractor  Logistic  Support 

CM 

Configuration  Management 

CMM 

Coordinate  Measurement  Machine 

CMSE 

Commercialization  of  Military  and  Space  Electronics 
Conference 

COTS 

Commercial  Off  the  Shelf 

DAU 

Defense  Acquisition  University 

DEMS 

Defense  Reutilization  and  Marketing  Service 

DMEA 

Defense  Microelectronics  Activity 

DMS 

Diminishing  Manufacturers  Supply 

DMSMS 

Diminishing  Manufacturing  Sources  and  Material  Shortages 

DoD 

Department  of  Defense 

E&MD 

Engineering  and  Manufacturing  Development  Phase 

ECP 

Engineering  Change  Proposal 

F3I 

Form,  Fit,  Functional  replacement 

FAR 

Funding  Allocation  Review 

FY 

Fiscal  Year 

GIA 

Government  Industry  Association 

GIDEP 

Government  Industry  Data  Exchange  Program 

Govt. 

Government 

H 

High  Risk 

ICP 

Inventory  Control  Point 

IEEE  1722 

Capability  Assessment  Tool 

ILS 

Integrated  Logistics  Support 

IPT 

Integrated  Product  Team 

ISEA 

In-Service  Engineering  Agent 
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ITIMP 


Ktr 

L 

LCC 

LT 

LTB 

LSA 

M 

MAN-YR 

MIL-Spec 

MIN/MAX 

MKI 

MKII 

MOU 

MSP-Plus 

MT 

MVP 

NAVAIR 

NAVICP 

NAVSEA 

NDIA 

NRFI 

NSWC/Corona 

NSWC/Crane 

OEM 

OFPP 

OJT 

OMB 

#  programs 

PBC 

PBL 

PBL-0 

PBL-C 

PBL-MSP 

PBL-P 

“FuH”-PBL 

PEO 

PHS&T 

PM 

PMO 

POC 

POM 

PPBS 

R&D 


Integrated  Technical  Item  Management  and  Procurement 

System 

Contractor 

Low  Risk 

Life  Cycle  Cost 

Long  term  supportability  -  greater  than  ten  years 
Life  of  Type  Buy  (also  referred  to  as  LOT  Buy) 

Logistics  Support  Analysis 
Medium  Risk 

Level  of  effort  for  one  person  over  one  year 

Military  Specifications 

minimum/maximum 

SSDS  Mark  I  System 

SSDS  Mark  II  System 

Memorandum  of  Understanding 

PBL-MSP  with  MIN/MAX  stocking  requirements 

Mid  Tenn  supportability  -  five  to  seven  years 

Most  valuable  performer 

Naval  Air  Systems  Command 

Naval  Inventory  Control  Point 

Naval  Sea  Systems  Command 

National  Defense  Industrial  Association 

Not  ready  for  issue 

Naval  Surface  Warfare  Center,  Corona  Division 

Naval  Surface  Warfare  Center,  Crane  Division 

Original  Equipment  Manufacturer 

Office  of  Federal  Procurement  Policy 

On  the  job  training 

Office  of  Management  and  Budget 

Number  of  program 

Perfonnance  Based  Contracting 

Perfonnance  Based  Logistics 

Performance  Based  Logistics  Organic 

Performance  Based  Logistics  Contractor 

Performance  Based  Logistics  -  Mini  Stock  Point 

Performance  Based  Logistics  Partnership 

Performance  Based  Logistics  -  Contractor  exercises  full 

control 

Program  Executive  Offices 

Packaging,  Handling,  Storage  and  Transportation 

Program  Manager 

Program  Management  Office 

Point  of  Contact 

Program  Objective  Memorandum 
Programming,  Planning  and  Budgeting  System 
Research  and  Development 
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ROI 

Return  on  Investment 

ROM 

Rough  order  of  magnitude 

SECNAV 

Secretary  of  the  Navy 

SEDI 

Systems  Engineering  Development  and  Implementation  Plan 

SOW 

Statement  of  Work 

SPA  WAR 

Space  and  Naval  Warfare  Systems  Command 

SSB 

Sunset  Supply  Base 

SSDS 

The  Ship  Self  Defense  System  developed  for  the  Navy  under 
the  program  management  code  PMS-461 

ST 

Short  Term  supportability  -  less  than  five  years 

SYSCOM 

Systems  Command  Structure 

SWOT 

Strengths,  Weaknesses,  Opportunities,  and  Threats  Analysis 

TOC 

Total  Ownership  Cost 
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I.  EXECUTIVE  SUMMARY 


This  Marketing  Plan  is  one  of  the  four  foundational  documents  created  to 
establish  the  SSB  system  as  a  Commercial  off  the  Shelf  (COTS)  supportability  alternative 
for  Navy  fielded  systems  containing  COTS  products.  The  SSB  concept  is  a  unique  After- 
Market  approach  to  extend  the  supportability  of  COTS  products  predicated  on  the  needs 
of  Navy  Programs.  The  extension  of  product  availability,  beyond  the  OEM  assigned  date 
to  drop  the  products  as  obsolete  items,  provides  stability  to  the  system  baseline 
configuration,  during  periods  of  time  between  installation  and  scheduled  Technical 
Refresh/  Insertion.  The  uniqueness  of  the  SSB  concept  is  evident  through  how  it  is 
structured.  The  OEMs  are:  a)  market  driven,  b)  high  volume  and  high  technology,  c) 
their  business  plan  is  driven  by  their  commercial  customer  base,  with  only  about  0.4  %  of 
their  business  going  to  Department  of  Defense  (DoD)  [1)  Glum,  2)  Robinson,  3) 
Hartshorn]  and  d)  experience  fast  update  cycles  (<  18  months)[l)  Glum,  2)  Robinson,  4) 
McDermott].  In  contrast  to  these  OEM  attributes,  DoD  has:  1)  unique  applications  with 
lengthy  life  cycles  (20-40  years),  2)  requires  a  minimum  technology  refresh  or  update 
cycle  of  not  less  than  5  years  [4)  McDermott],  and  3)  have  operational  readiness  and 
maintainability  support  issue  that  span  the  entire  life  cycle.  To  bridge  the  gap  between 
the  OEM  business  planning  and  the  Navy’s  need  for  long  tenn  support  a  third  party  is 
brought  in.  This  is  the  Sunset  Supplier.  The  Sunset  Supplier  makes  a  contractual 
relationship  with  the  OEM  to  produce  the  obsolete  products  for  the  OEM  customer  base. 
The  OEM  transfers  the  intellectual  property  and  assembly  know-how  to  the  Sunset 
Supplier  and  for  this  the  OEM  receives  royalty  on  the  sale  of  all  products  produced. 
Internal  to  the  Navy  are  support  infrastructures  to  ensure  supportability  of  sunset  products 
by  mitigating  any  component  part  obsolescence  issues  if  they  exist  on  those  products. 
The  infrastructure  and  support  of  the  SSB  process  yields,  not  only  significant  cost 
savings,  but  also  provides  other  benefits,  such  as: 

•  Supportability  of  products  defined  by  customer  need  (5,  10,  15,  20  years.) 

•  Life  Cycle  Cost  (LCC)  savings,  due  to  no  life-time  buy  at  the  assembly  level 

is  needed,  so  the  assemblies  are  procured  as  the  customer  requires  them. 

•  Reparability  of  assemblies  over  the  designated  life  cycle(5,  10,  15,  20  years) 
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•  Hardware/Software/Finnware  stability  between  Technology  Refresh/Insertion 

Cycles. 

•  Significant  reduction  in  program  risk  as  related  to  COTS  and  life  cycle 

management. 

•  Improved  schedule  flexibility  and  support  options  that  can  be  tailored  for 

Fleet  needs. 

•  Minimal  or  no  impact  on  system  operational  performance.  The  perfonnance 

will  remain  constant  through  the  use  of  exactly  the  same  part:  form,  fit, 
and  function  replacement,  which  has  been  made  by  the  alternate 
manufacturer,  the  Sunset  Supplier. 
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II.  ENVIRONMENTAL  ANALYSIS 


A.  THE  EXTERNAL  ENVIRONMENT 

1 .  Competitive  F orces 

The  Sunset  Supply  Base  (SSB)  system  is  designed  to  work  with  existing  support 
systems  as  an  interfacing  method  to  optimize  solutions  in  managing  the  obsolescence  risk 
on  Commercial-off-the-shelf  (COTS)  electronic  products.  The  environment  of 
Diminishing  Manufacturer  Sources  and  Material  Suppliers  (DMSMS)  is  complex 
because  each  of  the  groups  or  entities  set  up  to  address  these  issues  are  established  and 
function  independently  of  any  other  entity.  There  are  many  working  groups  functioning 
independently  and  concurrently.  [5)  Overstreet]  Below  are  some  examples: 

1)  Department  of  Defense  level 

2)  Each  of  the  services  (Army,  Navy,  Air  Force,  Marine  Corps) 

3)  The  Defense  Logistics  Agency 

4)  Most  major  Program  Management  Offices  (PMO)  have  programmatic  teams 
and  many  other  lower  level  groups  and  teams  that  have  been  established  just 
within  the  Department  of  Defense. 

5)  Every  major  prime  contractor  to  DoD,  establishes  their  own  internal  working 
groups  and  teams. 

6)  Most  of  the  well-established  industry  working  groups,  associations,  and 
societies  also  have  set  up  teams  or  groups  to  work  the  DMSMS  issues. 

Although  the  SSB  system  is  designed  to  work  with  this  diversity  of  incongruent 
problem  solvers,  not  all  participants  perceive  it  in  that  context.  Competitive  attributes  or 
characteristics  that  will  impede  or  totally  block  the  SSB  system  can  be  categorized  into 
several  groups. 

B.  COMPETITION  CATEGORIES 

1.  Resource  Competition 

In  this  category  the  available  resources,  primarily  funding,  take  priority  over 
incorporating  another  way  to  do  business  even  if  it  is  better  and  more  appropriate  in 
lowering  the  obsolescence  risk  to  the  program  or  entity  evolved.  This  type  of  view  point 
looks  at  the  funding  potential  as  a  zero  sum  game  —  if  they  need  to  add  another  group  or 
function,  the  end  result  is  less  funding  to  the  existing  funded  groups  or  entities.  This 
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barrier  to  entry  is  more  complex  than  providing  a  compelling  business  case  for  the  SSB 
systems  inclusion,  it  will  require  a  cultural  shift  to  work  collaboratively  instead  of 
competitively.  Some  extremely  active  and  powerful  groups  within  this  category  are  the 
DoD  and  service  branch  (Army,  Navy,  etc.)  field  activities.  This  behavior  is  referred  to 
as  a  “rice  bowl”  mentality  and  has  a  long-standing  tradition  with  a  complete  culture  that 
supports  it. 

2.  Territorial  Competition 

Each  entity  has  its  reasons  in  taking  care  of  its  own  problems  and  challenges. 
Among  these  reasons  the  most  prominent  is  self-preservation,  that  is,  being  perceived  as 
the  activity  or  entity  of  choice  when  the  customer  needs  DMSMS  issues  resolved.  This 
situation  has  always  existed  but  it  was  exacerbated  when  the  Acquisition  Reform  (AR) 
policies  and  practices  encouraged  competition  between  the  various  support  functions. 
Entrance  of  the  SSB  system  into  the  existing  DMSMS  tools,  methods,  and  processes  is 
viewed  as  an  undefined  risk  and  possibly  as  a  territorial  breach.  Territorial  boundaries 
are  expected  across  service  branches  but  in  the  case  of  DMSMS  the  boundaries  can  be 
scribed  down  to  the  lowest  level  working  groups  and  teams. 

3.  Contractual  Competition 

The  traditional  contracting  practices  are  being  displaced  by  a  new  set  of 
performance  based  contracts  that  shift  the  burden  of  responsibility  onto  the  contractor  for 
design,  manufacturing,  and  support.  These  contracts  may  take  various  degrees  of 
responsibility  sharing  between  the  government  and  the  contractor,  especially  with  respect 
to  support  of  fielded  systems.  Regardless  of  the  split  in  responsibility,  a  tension  between 
the  customer,  the  government,  and  the  contractor  usually  develops  regarding  DMSMS 
management.  Here  the  golden  rule  applies  -  “He  who  has  the  gold,  makes  the  rules”.  In 
terms  of  the  competitive  environment,  the  issues  affecting  DMSMS  resolutions  will  be 
decided  when  the  funds  and  contracted  responsibility  are  partitioned  with  the  only  real 
arbitrator  being  the  way  the  contractor  receives  incentives  through  the  contract  language. 

4.  Functional  Competition 

Although  the  utility  of  having  an  Integrated  Product  Teaming  (IPT)  environment 
has  been  well  documented,  a  good  percentage  of  the  working  groups  and  teams  do  not 
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implement  the  concepts.  The  impact  to  the  DMSMS  efforts  due  to  lack  of  an  IPT 
environment  is  a  fragmented  approach  that  produces  “Stovepipe”  functional  group 
activities.  These  “Stovepipe”  activities  lack  the  overarching  cohesive  structure  provided 
by  a  Systems  Engineering  approach  and  many  times  yield  functional  areas  where 
protectionism  and  information  hiding  is  an  accepted  practice.  An  IPT  environment  will 
be  composed  of  some  combination  of  the  following  functions:  DMSMS  specialists, 
Integrated  Logistic  Support,  Sustainment  Engineering,  design  engineering,  procurement, 
contracts,  business  management,  and  Program  Management  Office  (PMO)  —  and  these 
functions  must  work  together  in  developing  solutions.  The  impact  of  the  “Stovepipe” 
mindset  by  any  one  function  may  limit  the  potential  solution  options.  The  SSB  system  as 
a  solution  option  is  designed  to  impact  every  functional  area  on  the  support  team  and, 
when  interfacing  with  this  isolationist  disposition,  will  challenge  that  functional  area  to 
participate.  The  SSB  system  is  a  collaborative  system  that  necessitates  voluntary 
participation  and  if  a  functional  area  uses  the  “Stovepipe”  mentality  it  becomes  readily 
apparent  to  the  entire  team  as  an  area  of  concern.  The  inevitable  confrontation  between 
the  SSB  system  and  the  isolationists  will  usually  be  exhibited  as  functional  competition. 
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III.  THE  MARKET  PLACE  &  THE  PLAYERS 


A.  THE  MARKETS 

There  are  three  primary  market  segments,  which  constitute  the  microelectronics 
market  place  each  with  a  unique  environment.  The  microelectronic  market  place  is 
important  to  the  DoD/military  consumers  because  the  majority  of  the  weapons  and 
support  systems  derive  their  functionality  and  performance  from  the  microelectronics 
attributes.  There  are  three  primary  market  segments  each  with  a  unique  environment  that 
constitute  the  Market  Place.  The  first  of  these  segments  is  the  commercial  market; 
characterized  by  fast  paced,  intense  competition,  driven  by  market  forces,  and  state-of- 
the-art  technology  and  innovation.  This  commercial  market  segment  (89.5%)  is 
illustrated  in  Figure  1  [3)  Hartshorn]  and  is  the  sum  of  the  combined  sub-markets  of 
Communication  (16.8%),  Consumer  (12.3%),  Auto  (5.1%),  and  Computers  (55.3%).  The 
perception  of  supportability  for  fielded  products  given  this  market  driven  environment,  is 
that  of  upgrading  to  the  newest  technology  on  a  continuous  basis  and  retire  the  older 
technology.  The  approach  taken  regarding  the  COTS  obsolescence  risk  is  viewed  by  this 
segment  as  an  opportunity  to  sell  more  of  the  newer  products  because  the  products  are 
considered  either  throw  away  items  or  the  cost  of  doing  business.  This  segment  is  by  far 
the  largest  consumer  of  the  COTS  products  and  therefore  the  prime  motivational  force 
which  drives  the  Original  Equipment  Manufacturers  (OEMs). 

The  second  largest  customer  of  COTS  products  making  up  the  next  segment  of 
the  market  is  the  industrial  consumer  (10.1%).  This  segment  has  a  whole  range  of 
applications  and  consumption  habits.  Depending  on  the  application,  the  amount  of 
capital  investment  and  type  of  competitive  pressures,  taken  together,  will  determine  the 
approach  taken  regarding  the  COTS  obsolescence  risk.  The  industrial  segment  consumes 
COTS  products  in  the  mid  range  of  volume,  incorporating  them  as  part  of  the  end  item  to 
sell  or  used  in  producing  some  other  product  such  as  their  use  in  paper  mills,  petroleum 
distillate  plants,  and  in  pharmaceutical  manufacturing  facilities.  The  impact  of 
obsolescence  on  those  COTS  products  consumed  to  make  end  products  is  considered 
minimal  because  the  end  products  are  redesigned  to  accommodate  the  newer  versions  or 


397 


newest  technology  offered  by  the  market;  typically  these  type  end  products  have  minimal 
support  and  certification  requirements.  The  other  primary  application  for  COTS  products 
consumed  by  the  industrial  segment  integrates  these  COTS  products  into  larger  systems, 
which  are  capitally  intensive  and  configuration  constrained.  Examples  of  these  types  of 
systems  include  such  items  as  aircraft,  industrial  production  facilities,  medical 
equipment,  safety  and  life  support  equipment.  Many  of  these  systems  necessitate 
additional  support  requirements  such  as  certification  or  complex  and  involved  start-up 
processes  taking  up  to  a  year  to  get  online.  The  smallest  of  the  three  primary  segments  is 
the  government  procurement  (0.4%)  portion  of  the  market,  consumed  predominately  in 
the  defense  products.  This  small  segment  has  a  greater  amount  of  constraints  levied 
against  it  than  any  other  market  segment.  The  government  segment  is  capitally  intensive 
and  configuration  constrained  with  the  additional  burden  of  being  a  highly  regulated 
environment. 


Year  2001  Semiconductor  Usage 

f31G  Billion  Dollar  Market* 


Auto 

5.1% 


Military 

0.4% 


Appendix  D  Figure  1:  Year  2001  Semiconductor  Usage 
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DECLINING  MILITARY  PRESENCE 


Total  Semiconductor  Market 
Total  Military  Market 
Military  %  of  Market 


Appendix  D  Figure  2:  Declining  Military  Presence 

1.  The  Players 

The  players  involved  with  the  first  market  segment  are  the  buyers  of  the  general 
electronic  products.  This  market  includes  such  items  as:  games,  personal  computers, 
stereos,  calculators,  handheld  computers,  televisions,  CDs,  video  recorders/players  or  any 
of  the  millions  of  consumable  electronic  devises  in  the  general  market  place.  Although 
studies  and  segmentation  of  this  portion  of  the  market  could  be  done  it  is  not  within  the 
scope  of  this  evaluation.  The  important  thing  to  realize  is  that  it  is  this  diverse  market 
segment  which  provides  the  driving  motivational  force  for  change  and  innovation  in  the 
COTS  products.  These  market  driven  forces  directly  impact  the  rate  of  change  in  the 
products  and  the  subsequent  short  cycle  times  from  product  introduction  to  product 
discontinuance  resulting  in  the  obsolescence  of  the  COTS  products. 

The  industrial  market  place  is  divided  into  two  groups:  the  followers  and  the 
extended  users.  The  follower  group  has  the  capability  to  track  their  use  of  COTS 
products  with  the  commercial  market  place  and,  because  of  their  niche  market 
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applications,  can  completely  sidestep  the  obsolescence  risk  issues  of  the  COTS  products. 
The  players  in  this  group  of  the  industrial  market  do  not  play  an  influential  role  in 
mitigation  methods  for  the  obsolescence  risk  for  COTS  products  and  therefore  are  not 
considered  within  scope  for  this  evaluation.  The  industrial  market  extended  users,  on  the 
other  hand,  have  an  investment  in  the  capital  equipment  and  many  are  accompanied  by 
additional  constraints.  Two  such  constraints  are:  1)  frozen  baseline  configuration  of 
capitally  intensive  equipment,  and  2)  certification  or  process  requirements.  An  example 
of  the  first  constraint  is  a  chemical  processing  plan  which  may  take  up  to  5  years  to 
design,  3-5  years  to  build,  and  up  to  1-2  years  to  balance  and  bring  into  equilibrium  for 
constant  processing  of  end  products.  The  second  typical  constraint,  that  of  certification, 
can  come  in  many  different  forms:  Food  and  Drug  Association  (FDA)  (US  &  foreign 
countries),  Federal  Aviation  Administration  (FAA),  Nuclear  Regulatory  Commission 
(NRC),  safety  certifications,  food  handling,  and  a  host  of  other  well  defined  approval  and 
certification  requirements.  Regardless  of  the  type  of  constraints,  this  market  segment 
must  identify  and  mitigate  the  obsolescence  risk  due  to  COTS  products  in  order  to 
maintain  the  supportability  of  their  fielded  systems.  The  players  involved  with  this 
market  segment  are  extremely  complicated  to  define  because  it  depends  on  a  number  of 
factors  such  as:  type  of  industry,  the  company  organizational  structure,  the  structure  and 
requirements  of  the  certifying  entity  (i.e.  FDA  may  require  a  doctor’s  assessment,  where 
as,  FAA  may  call  on  in-house  FAA  experts  to  perform  evaluations,  etc.).  The 
perturbations  imbedded  within  all  these  possibilities  yields  a  set  of  players  that  has  too 
much  variability  to  categorize  into  neat  groupings  and  therefore  must  be  lumped  into  the 
large  grouping  of  the  entire  market  segment.  For  the  purposes  of  this  market  study  the 
influence  and  impact  of  the  entire  group  will  be  taken  into  account  where  applicable. 

The  final  market  segment,  the  government  segment,  has  a  large  and  diverse  group 
of  players  and  are  the  primary  focus  of  this  marketing  plan.  The  position  in  the  market 
place  of  the  government  segment  group  has  shifted  drastically  over  the  past  thirty  years  to 
a  minor  participant  (0.4%)  as  depicted  graphically  in  Figure  2  [3)  Hartshorn],  leaving  the 
players  in  this  group  with  little  or  no  leverage  in  the  overall  market  place.  As  mentioned 
earlier  these  players  come  from  various  areas:  at  the  DoD  level  down  to  the  lowest  level 
program  working  team,  all  work  the  DMSMS  issues.  Furthermore  the  DMSMS  issues  are 
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system  issues  requiring  teaming  from  all  functional  areas:  ILS,  Sustainment  Engineering, 
design  engineering,  procurement,  contracts,  business  management,  and  PMO,  from  the 
government  side  of  the  house  and  from  the  contractors  side  of  the  house.  Although  many 
support  groups  have  been  formed  to  provide  help,  guidance,  and  support  the  final 
responsible  entity  for  the  long  tenn  supportability  of  fielded  hardware  is  the  Program 
Manager  (PM)  for  the  program.  In  many  cases  the  PMOs  are  grouped  into  larger  entities 
called  Program  Executive  Offices  (PEO)  and  will  sometimes  function  cohesively  when 
addressing  DMSMS  issues  although  never  in  complete  concert  with  each  other  —  the  net 
result  is  that  the  DMSMS  issues  are  handled  at  the  PMO  level.  Therefore  the  primary 
players  regarding  DMSMS  issues  are  the  functional  participants  within  any  given  PMO 
and  all  other  entities  are  advisory  in  nature. 

Important  to  take  into  account  when  considering  the  various  players  and  their 
roles  in  the  COTS  environment  and  the  DMSMS  community  is  the  changing  contractual 
landscape  employing  Performance  Based  Logistics  (PBL)  and  Contractor  Logistic 
Support  (CLS)  [6)  DUSD  L&MR].  The  impact  of  these  contract  methodologies  is  the 
transference  of  responsibility  for  long  tenn  planning,  including  the  obsolescence  risk  due 
to  COTS  products,  to  the  contractor  while  subordinating  the  government’s  role  to  an 
advisory  capacity.  This  changing  contractual  landscape  has  a  direct  impact  on  who  the 
players  are  and  what  role  they  assume.  Therefore  the  company  contracted  using  PBL  or 
CLS  to  perfonn  support  functions  provides  another  competitive  force  when  considering 
the  SSB  system  as  a  potential  alternative.  When  using  the  PBL  or  CLS  type  contracts, 
the  primary  player  becomes  the  contractor.  The  competitive  issues  which  arise  with 
regard  to  the  SSB  system,  stem  from  the  fact  that  the  SSB  system  is  an  internal 
government  functional  system  and  not  readily  transferable  to  the  contractor.  The  inherent 
nature  of  the  SSB  system  necessitates  an  independent  third  party  to  collaborate  with 
OEMs  and  SSB  suppliers  to  optimize  the  best  value  for  the  government.  The  contractor 
on  the  other  hand,  has  as  their  primary  motivational  force  the  bottom  line  profit  and 
supporting  the  overall  business  case.  If  the  SSB  system  is  perceived  as  not  being  in  the 
contractor’s  best  interest  for  whatever  reason,  the  SSB  system  will  have  no  real  chance  of 
success.  The  key  strengths  of  the  contractor  as  a  competitor  are:  1)  the  contractor  many 
times  was  the  entity  who  designed  the  system  in  the  first  place  so  they  possess  intimate 
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knowledge  of  the  system,  2)  the  contractor  has  developed  working  relationships  with  the 
government  PMO  and  understands  the  program’s  structure,  the  political  environment,  and 
even  the  short  comings  of  the  system,  and  3)  typically  the  contractor  can  provide  full 
service  of  all  necessary  functions  (i.e.  engineering,  Integrated  Logistic  Support  (ILS), 
procurement,  test  and  evaluation,  configuration  management,  etc.). 

Given  the  above  scenario,  the  inherent  weaknesses  with  the  contractor  as  a 
competitor  are:  1)  since  the  SSB  system  is  uniquely  a  governmental  function  not  directly 
transferable  to  the  contractor,  the  contractor  must  search  for  other  methods  to  support  the 
COTS  products  over  the  long  term,  and  they  must  do  so  with  an  equivalent  level  of  cost, 
schedule,  and  perfonnance.  Since  no  other  system  has  been  identified,  tested,  and 
implemented  which  shows  the  same  efficiencies  as  the  SSB  system,  the  weakness  the 
contractor  must  contend  with  is  the  amount  of  risk  to  the  program  success  due  to  a  less 
efficient  support  process.  2)  The  contractor  will  have  and  inherent  conflict  of  interest  in 
supporting  COTS  long  term  because  of  competing  interests  within  their  own  company. 
As  stated  above,  PBL  &  CLS  are  typically  awarded  to  contractors  who  can  support  all 
functions  (i.e.  design,  maintenance,  procurement,  etc.)  and  the  company’s  business  case 
in  support  of  these  types  of  contractors  will  reflect  the  amount  that  each  functional  area 
within  the  company  will  contribute  to  the  bottom  line  profits.  Without  the  long-term 
support  of  COTS  products,  the  company  will  need  to  redesign  the  system  to 
accommodate  a  different  part  when  the  COTS  product  goes  obsolete  and  this  in  turn 
provides  profit  margins  for  the  engineering  functions.  These  profit  margins  from 
engineering  have  historically  been  the  cash  generator  as  compared  with  the  margins 
gained  through  ILS  or  procurement  functions  which  contribute  only  a  minor  amount  of 
cash  generation  potential.  When  using  the  SSB  System  for  the  long-term  supportability 
of  COTS  products  is  implemented,  the  subsequent  resulting  impact  to  the  engineering 
functions  will  yield  fewer  opportunities  for  redesign  and  therefore  negative  impact  to  the 
bottom  line  profits.  The  internal  conflicts  within  the  PBL/CLS  contractor  could  be 
resolved  to  maximize  the  bottom  line  profits  of  the  company  to  the  detriment  to  the 
supportability  of  fielded  Navy  system  and  unnecessary  negative  impacts  to  the  systems 
Life  Cycle  Cost  (LCC).  3)  These  large  full  service  contractors  are  burdened  by  the 
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contracting  constraints  of  doing  business  with  the  government  and  have  adjusted  their 
price  of  doing  business  accordingly  resulting  in  an  expensive  arrangement  for  the  Navy. 

2.  Market  Place  Size 

Although,  as  mentioned  above,  there  are  several  market  segments,  which  could  be 
analyzed  with  regard  to  utilizing  the  SSB  system,  for  the  purposes  of  this  analysis  we  will 
consider  only  a  subset  of  the  potential  market  place,  namely  the  Navy  PMOs.  Other 
potential  markets  such  as  “Industrial  segment  extended  users”  and  other  government 
users  (i.e.  Air  Force,  DOE,  Coast  Guard,  etc.)  will  be  treated  as  potential  future  markets 
but  will  not  be  characterized  with  respect  to  size  or  dollar  amounts.  Within  the  Navy’s 
System  Command  Structure  (SYSCOM)  there  are  three  major  SYSCOMs  which 
represent  the  lions  share  of  all  acquisition  programs  for  the  Navy  having  an  annual 
procurement  budget  totaling  approximately  $43.4  Billion  in  FY2001  [7)  Cowley]  and  of 
this  total  budget  only  a  small  fraction  is  spent  on  electronic  COTS  products.  Within  a 
SYSCOM  the  acquisition  programs  are  assigned  to  Program  Management  Offices 
(PMOs)  and  more  than  one  acquisition  program  may  be  assigned  to  a  PMO.  The  three 
major  SYSCOMs  and  the  quantity  of  acquisition  programs  associated  with  each  one  are 
as  follows:  Naval  Sea  Systems  Command  -  NAVSEA  with  134  programs  [8)  NAVSEA], 
Naval  Air  System  Command  -  NAVAIR  with  148  programs  [9)  NAVAIR],  and  Space 
and  Warfare  System  Command  -  SPAWAR  with  83  programs  [10)  SPAWAR].  The 
number  of  programs  for  each  SYSCOM  is  an  estimate  base  on  web  published 
information.  The  total  available  estimated  market  size  is  the  sum  of  all  programs  within 
the  Navy  and  that  value  is  365  programs. 

B.  ECONOMIC  GROWTH  AND  STABILITY 

The  economic  growth  and  stability  for  the  DMSMS  communities  is  in  a  growth 
mode  because  the  obsolescence  risk  issues  are  getting  worse  for  several  reasons:  1)  the 
use  of  COTS  products  has  been  endorsed  as  the  preferred  alternative  for  use  in  the  DoD 
systems,  as  identified  in  the  DoD  5000  series  documents  [11)  DoD,  12)  DoD,  13)  DoD], 
2)  the  service  life  extension  of  currently  fielded  systems  -  see  Figure  3  [14)  King],  and  3) 
the  fast  pace  that  our  Original  Equipment  Manufacturers  (OEM)  leave  the  market  with 
their  product  before  the  end  of  the  Navy’s  systems  service  life  and  sometimes  even 
before  the  system  is  fielded.  To  exacerbate  the  obsolescence  risk  issues,  the  support 
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structures  (i.e.  contracting,  procurement,  ILS,  etc.)  traditionally  used  by  the  Navy  were 
purposely  designed  to  be  conservative,  deliberate,  and  methodical  which  yielded  a  slow 
bureaucratic  system.  The  PMOs  being  the  responsible  entity  to  assure  the  supportability 
of  fielded  systems  have  in  the  past  and  will  continue  to  in  the  future  necessitate  funding 
and  support  of  DMSMS  activities  to  meet  the  Navy’s  ever  increasing  need. 


System  Life  Cycle  Extensions 

Notional  Project  Lifetime  Extended  Life 


Appendix  D  Figure  3:  System  Life  Cycle  Extensions 


C.  POLITICAL,  LEGAL,  AND  REGULATORY  TRENDS 


The  current  trends  which  take  on  overtones  of  political  and  legal  characteristics 
are  activities  involving  performance  based  contracting,  ranging  from  Performance  Based 
Logistics  (PBL)  to  Contractor  Logistic  Support  (CLS),  on  all  new  procurements  wherever 
possible  [7)  Cowley].  The  impact  to  the  existing  DMSMS  community  could  be 
significant  in  that,  the  support  responsibility  will  be  approached  in  a  more  rigorous 
manner  and  have  legal  ramifications  with  regards  to  the  contract.  There  are  political 
forces  pushing  for  contractor  involvement  in  support  of  fielded  systems  and  abandoning 
the  traditional  organic  support,  this  would  include  DMSMS  support  as  well.  Depending 
on  the  political  environment  and  the  contracting  methodology,  the  existing  DMSMS 
support  functions  and  the  SSB  system  could  be  excluded  from  participating.  Let  us 
explore  this  before  moving  on;  if  a  contract  is  being  evaluated  for  “Full”  PBL  to  include: 
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1)  engineering  evaluations,  both  new  and  in-service  support,  2)  Integrated  Logistic 
Support  (ILS),  3)  Maintenance  and  repair  support  (i.e.  Depot  level),  4)  Procurement 
support,  and  5)  DMSMS  support  -  and  the  contract  explicitly  states  these  functions  for  an 
indivisible  package  of  support,  then  the  DMSMS  support  function  must  go  with  the 
contract  if  it  is  to  be  awarded.  Traditionally  the  support  of  the  above  functions,  have 
been  accomplished  internally  in  the  Navy  but  the  functions  are  not  centrally  located  and 
are  dispersed  throughout  the  various  field  activities  and  in  the  PMO.  The  dispersed 
organic  functions,  in  order  to  participate  in  bidding  on  the  contract  must  collectively  and 
collaboratively  group  together  to  support  the  indivisible  package  of  support.  In  the 
current  internal  organic  support  environment  a  collaborative,  coordinated  response  is  not 
likely.  The  scenario  provided  above  is  not  unique  in  identifying  requirements  for  PBL 
contracts,  as  is  shown  in  Table  1  below.  Table  1  is  followed  by  the  definitions  of  the 
“Type  of  PBL”  so  that  a  better  understanding  of  the  table  can  be  achieved  by  providing 
context  to  the  information  presented.  Notice  that  under  the  column  heading  -  Provider 
manages  obsolescence  -  that  if  the  service  is  defined  as  being  incorporated  into  the 
contract,  the  function  always  rests  with  the  contractor,  although  as  a  potential  resolution 
the  contractor,  at  their  discretion,  may  hire  as  a  subcontractor  a  government  activity  or 
Organic  entity. 


Appendix  D  Table  1:  Illustrates  the  various  PBL  categories  and  their  associated  attributes 

D.  PERFORMANCE  BASED  LOGISTICS  DEFINITIONS 


The  following  categories  are  used  by  Naval  Inventory  Control  Point  (NAVICP)  to 
describe  the  various  types  of  PBL  arrangements  [15)  NAVICP]: 
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PBL-Mini-Stock  Point  (PBL-MSP): 

Navy  owns  the  inventory... contractor  receives,  stores,  issues,  and  may  also  repair 
the  material...  “MSP-Plus”  includes  a  negotiated  level  of  requirements  detennination 
(MIN/MAX). 

PBL-Organic  (PBL-O) 

An  arrangement  with  an  organic  activity  (normally  via  Memorandum  of 
Agreement)  to  procure,  repair,  stock  and  issue  material. 

PBL-Commercial  (PBL-C): 

An  arrangement  where  commercial  items  are  supplied  by  the  contractor. 
Customer  requisitions  are  automatically  routed  through  procurement  system  (ITIMP) 
directly  to  the  contractor  as  a  delivery  order. 

PBL-Partnership  (PBL-P): 

An  arrangement  between  a  contractor  and  Navy  such  that  the  Navy  performs  a 
portion  of  support  required  by  and  for  the  contractor.  For  example,  the  contractor  may 
sub-contract  the  Navy  to  perform  maintenance  support  at  an  organic  depot.  This  can  be 
highly  beneficial  when  addressing  Core  maintenance  issues,  in  that  the  Navy  is  able  to 
retain  Core  capability  while  acting  as  a  “sub”  to  the  contractor. 

“Full”  PBL: 

A  contractual  arrangement  where  the  contractor  manages  (and  may  also  own)  the 
inventory,  detennines  stockage  levels,  typically  repairs  NRFI  material,  and  is  required  to 
meet  specific  performance  metrics.  Requisitions  still  flow  through  ICP,  and  ICP  pays  the 
contractor  for  performance  but  bills  customers  traditionally.  Reliability  improvements, 
technology  insertion  and  reduced  obsolescence  may  be  some  of  the  inherent  benefits  of  a 
Full  PBL.  The  contractor  usually  is  given  Class  II  ECP  authority  and  in  some  cases  may 
also  have  configuration  control.  Additionally,  Logistics  Engineering  Change  Proposal 
(LECP)  arrangements  will  be  considered  a  subset  of  this  category  if  they  contain  supply 
support  clauses  that  fall  under  the  definition  noted  above. 

Total  Logistics  Support: 

A  most  robust  form  of  PBL  (typically  referred  to  as  Contractor  Logistics  Support 
(CLS)),  where  the  contractor  manages  most  or  all  facets  of  logistic  support  (i.e.  ILS 
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elements),  including  inventory  levels,  maintenance  philosophy,  training  manuals, 
PHS&T,  full  configuration  control,  support  equipment,  etc. 

Taken  over  time,  the  effects  of  this  type  of  contracting  will  decimate  the  Navy’s 
internal  DMSMS  support  capability  leaving  it  in  the  hands  of  the  contractors.  There  is  an 
important  tie  to  the  political  environment.  The  contractors  in  the  defense  industry  have, 
for  a  long  time,  been  lobbying  Congress  to  allow  them  more  control  over  the  systems 
they  design  and  develop.  These  contractors  have  a  great  deal  of  influence  with  the 
congressional  representatives,  in  that,  the  representative’s  constituencies,  may  and  often 
do,  work  for  these  large  defense  contractors.  Additionally  the  contractors  have  been 
known  to  move  manufacturing/assembly  operations  into  a  specific  congressional  district 
to  entice  a  favorable  and  supportive  political  ally.  With  the  past  years  of  declining 
defense  budget  for  new  acquisition  programs  and  the  natural  increase  of  the  support 
budget  being  spent  on  the  ageing  assets,  the  contractor’s  interest  in  the  support  portion  of 
the  market  has  intensified.  There  is  currently  no  counteracting  force  from  the  internal 
Navy  support  functions/activities  to  counter  balance  this  move  by  the  defense  contractors. 
The  perfonnance  based  contracting  process  is  a  mechanism  developed  to  shift  the  amount 
of  contractor  involvement  in  all  areas  and  of  special  interest  is  their  expanding  role  in  the 
support  area  of  the  market.  The  premise  for  the  argument  given  by  the  contractor  driving 
the  need  for  change  is  the  cost  reductions  possible  by  using  the  more  efficient  processes 
and  methods  available  at  the  contractors,  and  in  leveraging  the  industrial  base 
community.  The  foundation  documents,  discussed  in  subsequent  paragraphs,  put  in  place 
to  establish  the  performance  based  contracting  methodology,  identify  this  cost  focus  as 
the  primary  discriminating  criteria.  The  guidance  documents,  discussed  in  subsequent 
paragraphs,  used  to  implement  the  methods,  go  beyond  the  cost  criteria  by  adding 
additional  caveats  and  restrictions,  such  as  an  “all  or  nothing”  involvement,  for 
functionally  different  but  related  portions  of  the  support  effort.  Furthermore,  by  dictating 
the  allocation  of  certain  functions  to  be  accomplished  by  specific  entities,  the  guidance 
documents  constrain  the  cost  focus  of  the  foundational  documents  potentially  yielding 
sub-optimal  results.  Other  considerations  regarding  the  guidance  documents  are  the 
methods,  tools,  and  processes  used  to  implement  the  requirements  of  the  document. 
These  practices  have  a  direct  impact  on  the  decisions  surrounding  the  award  of  the 
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performance  based  contracts.  Central  to  the  decision  making  process  regarding  the 
potential  use  of  a  PBL  contract  is  the  development  of  the  Business  Case  Analysis  (BCA). 
The  ground  rules  currently  used  in  developing  the  baseline  cost  estimates  for  Organic 
support  (i.e.  in-house  Navy  support  activity)  uses  historical  performance  data  and 
compares  this  data  with  contractor  proposed  estimates  in  evaluating  cost  effectiveness  of 
the  contractor’s  proposed  cost.  Important  to  notice  is  that  the  Organic  support  costs  rely 
solely  on  the  past  data  and  by  doing  the  analysis  in  this  manner  three  major  assumptions 
are  made:  1)  the  past  performance  data  is  accurate,  applied  in  an  appropriate  manner,  and 
the  data  reflects  current  and  future  performance  of  the  Organic  activities/functions,  2) 
there  are  no  opportunities  to  reduce,  streamline,  or  improve  the  Organic  cost  figures,  and 
3)  the  Organic  activities/functions  would  not  be  affected  by  the  competitive  environment. 
Applying  historical  costs  to  the  Organic  entities  and  comparing  these  to  the  cost  estimates 
in  a  proposal  from  the  contractor  yields  a  bias  in  favor  of  the  contractor.  Although  this 
type  of  analysis  is  considered  to  be  a  competitive  environment  where  the  lowest  cost  gets 
the  contract,  the  process  side  steps  many  of  the  tenets  of  true  competition.  The 
implementation  methods  employed  in  developing  perfonnance  based  contracts  handicaps 
the  Organic  activity/function,  provides  a  “non  level  playing  field”,  and  in  no  way  assures 
the  Navy  receives  the  best  possible  value  available  in  today’s  market  place. 

The  combination  of  the  change  in  focus  and  the  exclusionary  policies  invoked  by 
the  guidance  documents  and  implementation  policies,  defines  a  new  system  and,  as  in  all 
systems,  there  will  be  new  and  emerging  attributes  that  may  be  supportive  or  counter 
productive  to  the  initial  purposes  of  the  foundational  objectives.  One  of  these  counter 
productive  attributes  that  has  some  disturbing  unintended  consequences,  deals  with  a 
“built  in”  conflict  of  interest  for  the  contractor  during  the  perfonnance  period  of  the  PBL 
contract.  This  inherent  conflict  of  interest  is  a  result  of  the  interrelationship  between  the 
Engineering  Design  functions  and  the  Sustainment  Engineering  functions  providing 
DMSMS  support.  Since  both  of  these  functions  are  controlled  by  the  contractor  where 
non  Organic  support  methods  are  used,  decisions  will  necessitate  the  trade-off  between 
better  bottom  line  profits  for  the  company  or  best  value  for  the  Navy  evident  in  lowest 
Life  Cycle  Cost  (LCC)  and/or  Total  Ownership  Cost  (TOC).  To  illustrate  this 
interrelationship,  Figure  4  identifies  a  typical  example  in  notional  graphical  form  and 
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provides  a  ready  reference  in  explaining  the  cause  and  effect  relationship  between  the 
two  functions  and  helps  uncover  the  inherent  conflict  of  interest  experienced  by  the 
contractor. 
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Appendix  D  Figure  4:  Performance  based  Contract  Scenarios 


Figure  4  Illustrates  two  scenarios  for  different  types  of  performance  based 
contracts:  PBL  -  C,  Performance  Based  Logistic  contract  having  the  contractor  as  the 
sole  provider,  PBL  -  P,  Performance  Based  Logistic  contract  having  the  contractor  as  the 
lead  and  partnering  with  Organic  activities/functions  to  provide  contract  support.  The 
type  of  Organic  support  specified  in  the  example  implements  the  SSB  system.  For  both 
scenarios  a  singular  occurrence  of  obsolescence  notice  for  a  generic  assembly  -  Board 
AA  -  provides  an  example  to  show  how  each  contract  type  typically  would  support  the 
program  given  current  PBL  implementation  practices. 


Most  PBL  -  C  contracts  are  written  for  a  period  of  a  5  year  support  window  with 
a  follow-on  Navy  option  for  another  5  years.  Included  as  part  of  the  contract 
responsibilities  are  the  DMSMS  issues,  that  occur  during  the  contract  period  but  support 
is  limited  to  the  contracted  period  only.  All  other  support  cost  and  subsequent  impacts 
regarding  the  obsolescence  issue  must  be  dealt  with  using  other  contracting  methods 
since  those  impacts  are  beyond  the  scope  of  the  5  year  contracted  period.  Board  AA  in 
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the  example  given  above,  goes  obsolete  2  years  into  the  5  year  contracted  period.  In 
response  to  this  issue  the  contractor  is  obligated  to  provide  the  board  for  the  entire 
contracted  period  and  to  meet  this  commitment  the  contractor  most  often  will  chose  to 
perform  a  Life  of  Type  Buy  (LTB)  or  also  called  a  Bridge  buy.  Depending  on  the 
contract  language  the  contractor  may  or  may  not  be  required  to  notify  the  supported 
program  that  the  mitigating  activity  of  the  Bridge  buy  has  taken  place.  This  Bridge  buy 
indicates  a  future  risk  to  the  supportability  of  the  impacted  program.  Regardless  of 
notification  to  the  program  by  the  contractor  the  end  of  the  first  5  year  PBL  -  C  contract 
exposes  the  supportability  risk  to  the  program.  Even  if  the  program  was  notified  of  the 
impending  engineering  analysis  and  potential  redesign,  the  PBL  -  C  contracts  consider 
such  efforts  to  be  out  of  scope  and  therefore  must  be  dealt  with  another  way.  If  the 
program  had  chosen  to  do  nothing  about  the  notice  or  if  they  were  never  told  about  the 
issue,  the  program  can  no  longer  be  supported  by  Board  AA  and  another  alternative  must 
be  found,  typically  this  takes  up  to  2  years  for  full  qualification.  The  PMO  must  deal 
with  not  only  the  2  year  supportability  risk  but  they  must  also  pay  for  the  alternate 
solution  to  be  developed  and  implemented.  The  cost  for  such  solutions  have  large 
variability  but  for  minor  redesign  the  amounts  range  from  $22,400  to  $250,000  with  an 
average  of  $111,034  [16)  DMEA].  These  costs  identify  only  the  Design  Engineering 
efforts  which  does  not  include  the  other  necessary  support  functions/actions  (i.e. 
procurement,  Configuration  Management,  ILS  support,  etc.)  Provided  with  the 
comparison  between  the  PBL-C  and  the  PBL-P,  a  quick  inspection  of  the  notional 
graphical  example  illustrates  the  difference  between  the  two  contracting  methods 
predominantly  that  of  lower  risk  and  less  cost  of  the  PBL-P  support.  This  PBL-P  support 
method  should  be  considered  as  a  potential  alternative  method  of  support  and  contained 
within  the  solution  space.  In  an  effort  to  examine  the  total  environment  with  respect  to 
the  political,  legal,  and  contracting  issues,  a  detailed  review  of  both  the  foundational  and 
implementation  guidance  documents  will  be  accomplished  so  that  potential  alternative 
paths  can  be  uncovered.  However,  prior  to  looking  at  these  regulatory  documents  the 
role  that  engineering  plays  in  the  decision  making  processes  needs  to  be  expanded  upon 
in  order  to  overlay  the  context  of  the  supportability  issues  to  the  Life  Cycle  Cost  (LCC) 
impacts. 
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The  engineering  functions  are  all  about  Trade-offs  and  balance  of  requirements 
and  needs.  In  the  example  provided  in  Figure  4,  it  is  readily  evident  that  there  are  Trade¬ 
offs  between  the  Sustainment  Engineering  function  and  the  Design  Engineering  function, 
in  that,  one  function  can  and  will  affect  the  inclusion  or  exclusion  of  the  other  function. 
This  interrelationship  has  an  important  association  to  the  type  of  response  the  PMO  will 
receive  from  a  sole  source  contractor  controlling  both  functions  when  providing 
supportability  alternatives.  If  the  contractor  was  able  to  provide  a  support  system  that 
was  of  such  a  high  quality  that  is  was  the  most  cost  effective,  lowest  risk,  and  provided 
the  perfonnance  that  met  the  customers  needs,  then  the  impact  may  take  the  Design 
Engineering  function  completely  out  of  the  solution  space.  Conversely,  if  the  perfect 
design  solution  was  formulated  to  allow  an  easily  upgradeable  system  at  lowest  cost,  with 
no  impact  to  operations,  then  the  Sustainment  Engineering  function  would  drop  to  an 
extremely  low  amount.  Although  both  cases  stated  here  are  hypothetical,  it  is  important 
to  realize  the  Trade-offs  that  must  be  undertaken  when  considering  alternatives  for  a 
particular  solution  space.  Some  solutions  within  this  solution  space  are  less  than 
desirable  for  the  Navy.  Remembering  that  one  of  the  primary  driving  parameters,  which 
must  be  satisfied  by  the  contractor,  is  to  achieve  the  best  bottom  line  profits,  this  includes 
all  functions  and  operations.  Combining  this  bottom  line  focus  with  the  current 
implementation  guidelines  provides  unintentional  incentives  for  the  contractor  to 
optimize  the  bottom  line  focus  for  both  functions,  instead  of  providing  the  “best  value” 
for  the  Navy.  The  current  guidance  documents  ignore  the  need  for  the  “checks  and 
balances”  in  providing  good  tension  to  obtain  the  best  possible  solution.  Like  “cost  and 
performance”  as  a  pairing  provide  good  tension,  Sustainment  Engineering  and  Design 
Engineering  need  to  be  paired  to  compare  and  contrast  various  alternatives  in  the  solution 
space.  Furthermore,  these  engineering  discipline  areas  must  be  independently  evaluated 
or  decoupled  from  one  another  to  maintain  this  good  tension.  As  a  result  of  the  bottom 
line  incentive  focus  of  our  contractors,  independent  evaluation  or  decoupling  of  the  two 
engineering  functions  is  impractical  and  may  be  impossible.  Given  the  current  guidelines 
for  PBL  contracting,  our  contractors  are  provided  incentives  to  yield  solutions,  which 
may  not  be  and  probably  are  not  optimal  for  the  Navy.  Understanding  the  current  status 
of  incentives  provided  to  the  contractor  and  the  potential  outcome  is  important  in 
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considering  better  alternatives  that  provide  the  good  tension  in  an  effort  to  achieve  the 
“best  value”  for  the  Navy.  Until  other  incentives  are  available  which  provide  the  “good 
tension”  scenarios,  that  can  provide  “best  value”  for  the  Navy,  perhaps  the  DMSMS 
support  functions  should  not  be  contracted  out  but  kept  as  an  in-house  function.  The 
most  appropriate  alternative,  given  the  current  contracting  methods,  is  to  define  the 
Sustainment  Engineering  function,  especially  with  regards  to  DMSMS  solutions,  as  an 
inherently  governmental  function.  The  amount  of  judgment  calls  and  decisions  made  in 
developing  DMSMS  solutions  will  by  default  define  latter  actions  to  be  taken  by  the 
PMO  in  contracting  for  goods  and  services.  With  the  current  guidance,  the  PMO  may  or 
may  not  be  informed  of  these  decisions  and/or  possibilities,  whereby  the  contractor  in 
essence  makes  future  PMO  decisions  because  of  today’s  DMSMS  solutions  alternatives. 
The  net  result  of  the  interaction  between  current  decisions  and  future  decisions,  with  or 
without  the  PMO  knowledge,  identifies  a  situation  in  which  the  contractors  are  at  their 
discretion  making  PMO  decisions.  As  identified  below  in  review  of  the  foundational  and 
guidance  documents,  these  types  of  involved  decision-making  processes  are  reserved  for 
inherently  governmental  functions  only.  However,  due  to  variability  in  the  contracting 
process  the  DMSMS  support  functions  are  at  times  contracted  out  using  the  PBL 
contracting  methods.  Therefore  the  contracting  environment  (i.e.  competitive,  non¬ 
competitive)  as  identified  by  the  foundational  and  guidance  documentation  should  be 
reviewed. 
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IV.  THE  PERFORMANCE  BASED  CONTRACTING 

ENVIRONMENT 


In  this  section  the  direction  provided  through  both  sets  of  documents, 
foundational  and  guidance,  will  be  evaluated  with  respect  to:  1)  Responsibility  of  the 
Contractor  versus  that  of  the  Government,  and  2)  The  Contracting  Environment.  These 
two  evaluation  criteria  were  chosen  to  address  the  questions:  What  if  -  DMSMS  support 
functions  were  defined  to  be  “inherent  Governmental  functions”  then  do  the  documents 
provide  adequate  definition  and  justification?  Secondly,  if  the  DMSMS  support 
functions  were  considered  a  commercial  activity  then  -  What  is  the  resulting  contracting 
environment,  as  defined  in  these  documents?  Finally  to  close  out  the  section  a  conclusion 
paragraph  will  summarize  and  identify  the  potential  impact  to  the  SSB  implementation 
efforts. 

A.  THE  FOUNDATIONAL  PERFORMANCE  BASED  CONTRACTING 

DOCUMENTATION 

The  following  references  and  documents  are  considered  as  the  foundational  set  of 
documents  in  evaluating  the  Performance  Based  Contracting  (PBC)  requirements: 

•  DoD  Directive  5000.1  [11)  DoD] 

•  DoD  Instruction  5000.2  [12)  DoD] 

•  DoD  Regulation  5000. 2-R  [13)  DoD] 

•  OMB  Circular  No.  A- 1 1  [17)  OMB] 

•  OMB  Circular  No.  A-76  [  1 8)  OMB] 

•  OMB  Circular  No.  A-76  [19)  OMB] 

B.  RESPONSIBILITY  OF  THE  CONTRACTOR  VERSUS  THAT  OF  THE 

GOVERNMENT 

The  5000  series  documents  identify  the  need  to  streamline  the  acquisition  and 
support  process  while  focusing  on  perfonnance  criteria  as  the  preeminent  evaluation 
characteristic.  These  documents  identify  Life  Cycle  Cost  (LCC)  and  Total  Ownership 
Cost  (TOC)  as  the  driving  mechanism  to  receive  “best  value”  for  the  DoD.  In  essence, 
the  5000  series  documents  describe  the  backdrop  for  changes  but  focus  on  “best  value” 
while  improving  the  support  system  for  the  warfighter.  The  methods,  processes,  and 
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tools  identified  in  the  documents  rely  heavily  on  the  use  of  a  Systems  Engineering 
approach  in  assuring  that  an  overarching  view  of  the  systems  life  cycle  process  is  taken 
into  account.  In  setting  the  stage  for  allowing  a  performance  based  contracting  approach, 
OMB  Circular  A-l  1  identifies  the  budgetary  process  wherein  Appendix  8  -  “Alternative 
Competitions  and  OMB  Circular  A-76”  -  describes  a  summary  of  a  referenced  document 
and  explains  how  the  cost  comparison  process  is  designed  to  deliver  “best  value”  to  the 
government:  Appendix  8  specifically  states: 

Circular  A-76  provides  a  minimum  level  of  analytic  rigor  for  the 
evaluation  of  these  alternatives.  It  is  designed  to:  (1)  balance  the  interests 
of  the  parties;  (2)  provide  a  level  playing  field  between  public  and  private 
offerors;  and  (3)  encourage  competition  and  customer  choice. 

With  these  expectations  from  the  budgetary  process  in  mind  we  will  next  look  at 
the  requirements  provided  in  OMB  Circular  A-76.  The  A-76  first  identifies  what  an 
inherently  Governmental  function  is  and,  due  to  the  impact  this  definition  has  on  the 
requirements  detailed  in  the  remainder  of  the  document,  it  is  important  to  understand  this 
perspective.  As  part  of  the  definition  description,  the  following  statements  are  extracted 
from  the  full  text: 

An  inherently  Governmental  function  is  a  function  which  is  so  intimately 
related  to  the  public  interest  as  to  mandate  performance  by  Government 
employees.  Consistent  with  definitions  provided  in  the  Federal  Activities 
Inventory  Act  of  1998  and  OFPP  Policy  Letter  92-1,  these  functions 
include  those  activities  which  require  either  the  exercise  of  discretion  in 
applying  Government  authority  or  the  use  of  value  judgment  in  making 
decisions  for  the  Government... Inherently  Governmental  functions 
normally  fall  into  two  categories:  (1)  The  act  of  governing;  i.e.,  the 
discretionary  exercise  of  Government  authority.  Examples  include.... 
combat  support  or  combat  service  support  role... selection  of  program 
priorities;  direction  of  Federal  employees...  [20)  OFPP] 

Due  the  nature  and  long-term  impacts  with  regards  to  DMSMS  support  functions 
and  their  irreversible  influence  on  future  PMO  decisions,  the  issue  of  the  “act  of 
governing”  is  as  real  problem  which  could  yield  blanket  approval  authority  to  the 
contractor  to  act  on  behalf  of  the  PMO.  To  add  additional  perspective  regarding 
inherently  Governmental  functions  a  review  of  the  OFPP  Policy  Letter  92-1  yields  the 
following  descriptions: 
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Agencies  have  occasionally  relied  on  contractors  to  perform  certain 
functions  in  such  a  way  as  to  raise  questions  about  whether  Government 
policy  is  being  created  by  private  persons... 

As  a  matter  of  policy,  and  “inherently  governmental  function”  is  a 
function  that  is  so  intimately  related  to  the  public  interest  as  to  mandate 
performance  by  Government  employees.  These  functions  include  those 
activities  that  require  either  the  exercise  of  discretion  in  applying 
Government  authority  or  the  making  of  value  judgements  in  making 
decisions  for  the  Government... 

An  inherently  governmental  function  involves,  among  other  things,  the 
interpretation  and  execution  of  the  laws  of  the  United  States  so  as  to: 

(a) bind  the  United  States  to  take  or  not  to  take  some  action  by  contract, 
policy,  regulation,  authorization,  order,  or  otherwise; 

(b) determine,  protect,  and  advance  its  economic,  political,  territorial, 
property,  or  other  interests  by  military  or  diplomatic  action,  civil  or 
criminal  judicial  proceedings,  contract  management,  or  otherwise... 

(d) Commission,  appoint,  direct,  or  control  officers  or  employees  of  the 
United  States;  or 

(e)  exert  ultimate  control  over  the  acquisition,  use  or  disposition  of  the 
property,  real  or  personal,  tangible  or  intangible,  of  the  United  States...” 

7.  Guidelines...  (a)  The  exercise  of  discretion.  While  inherently 
governmental  functions  necessarily  involve  the  exercise  of  substantial 
discretion,  not  every  exercise  of  discretion  is  evidence  that  such  a  function 
is  involved.  Rather  the  use  of  discretion  must  have  the  effect  of 
committing  the  Federal  Government  to  a  course  of  action  when  two  or 
more  alternatives  course  of  action  exist... 

7.  Guidelines... (b)  Totality  of  the  circumstances. ...(2)  The  degree  to  which 
official  discretion  is  or  would  be  limited,  i.e.,  whether  the  contractor’s 
involvement  in  agency  functions  is  or  would  be  so  extensive  or  his  or  her 
work  product  is  so  far  advanced  toward  completion  that  the  agency’s 
ability  to  develop  and  consider  options  other  than  those  provided  by  the 
contractor  is  restricted.... 

Appendix  A  to  OFFP  Policy  Letter  92-1-  The  following  is  an  illustrative  list  of 
functions  considered  to  be  inherently  governmental  functions: 
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6.  The  determination  of  Federal  program  priorities  or  budget  requests... 


7.  The  direction  and  control  of  Federal  employees  ... 

11...  (a)  determining  what  supplies  or  services  are  to  be  acquired  by  the 

Government... 

16.  The  determination  of  budget  policy,  guidance,  and  strategy. 

Summary:  Responsibility  of  the  Contractor  versus  that  of  the  Government 

A  short  summary  and  evaluation  of  the  extracted  portions  of  the  documents 
identified  above  will  provide  some  concise  understanding  in  determining  if  the  DMSMS 
support  functions  are  or  are  not  inherently  governmental  functions.  The  DoD  5000  series 
documents  provide  the  upper  most  level  of  guidance  and  the  context  for  implementation 
of  Performance  Based  Contracting  (PBC)  focusing  primarily  on  using  the  Systems 
Engineering  approach  to  yield  the  “best  value”  for  the  Navy.  OMB  Circular  No.  A- 11 
sets  the  expectation  from  a  budgetary  perspective  that  uses  OMB  Circular  No.  A-76 
criteria  resulting  in  an  environment  which:  balances  the  interest  of  the  parties,  provides  a 
level  playing  field,  and  promotes  competition  while  increasing  customer  choice.  The 
guidance  provided,  thus  far,  places  no  constraints  on  “what”  entity  is  performing  the 
function  and  specifically  in  our  case  does  not  identify  “who”  should  accomplish  the 
support  function  for  the  PMO.  The  next  set  of  extracts  from  the  OMB  Circular  No.  A-76 
and  the  OFPP  Policy  Letter  92-1  identify  several  instances,  which  must  be  taken  into 
account  when  deciding  “who”  is  the  appropriate  entity  to  perform  certain  functions  and 
engage  in  the  PMO  decision  making  processes.  Several  issues  are  described  which 
would  define  certain  functions  to  be  set  aside  as  “inherently  governmental  functions”  . 
The  primary  issues  identified  include: 

•  act  of  governing;  i.e.,  the  discretionary  exercise  of  Government  authority, 

•  use  of  value  judgment  in  making  decisions  for  the  Government, 

•  selection  of  program  priorities, 

•  direction  of  Federal  employees, 

•  bind  the  United  States  to  take  or  not  to  take  some  action, 

•  exert  ultimate  control  over  the  acquisition,  use  or  disposition  of  the  property, 
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•  committing  the  Federal  Government  to  a  course  of  action  when  two  or  more 

alternatives  course  of  action  exist, 

•  product  is  so  far  advanced  toward  completion  that  the  agency’s  ability  to 

develop  and  consider  options  other  than  those  provided  by  the  contractor 

is  restricted, 

•  determining  what  supplies  or  services  are  to  be  acquired  by  the  Government, 

and 

•  determination  of  Federal  program  priorities  or  budget  requests. 

Considering  the  discussion  regarding  the  impacts  that  DMSMS  support  functions 
have  on  the  PMO’s  current  and  future  decision  making  processes,  then  applying  the 
definition  of  “inherently  governmental  functions”  some  logical  conclusions  can  be  drawn 
regarding  the  DMSMS  functions.  As  described  earlier  the  DMSMS  support  functions 
require  the  use  of  value  judgments  and  when  made,  dictate  the  future  discretionary 
exercise  of  Government  authority.  Furthennore  these  support  decisions  bind  the 
government  to  a  course  of  action,  sometimes  to  a  very  specific  course  of  action  like 
redesign.  Depending  on  the  support  strategy  the  DMSMS  support  decisions  may  lead  to 
scenarios  that  constrain  the  PMO’s  priorities,  budgets,  and  options  to  only  those  potential 
outcomes  identified  by  the  DMSMS  support  provider.  Additionally  the  highest  level 
guidance  documents,  the  DoD  5000  series,  endorse  the  use  of  the  Systems  Engineering 
approach  which  has  a  one  of  its  primary  tenets  -  the  use  of  “good  tension”  in  performing 
Trade-offs  and  achieving  “best  value”.  Previous  discussion  regarding  the  DMSMS 
support  functions  identified  the  “conflict  of  interest”  issue  when  a  contractor  had  total 
control  over  both  the  Sustainment  Engineering  and  Design  Engineering  functions.  The 
“conflict  of  interest”,  the  lack  of  having  “good  tension”,  the  use  of  value  judgments,  and 
the  irreversible  and  binding  decision  making  necessary  in  perfonning  the  DMSMS 
support  function  identify  these  functions  as  “inherently  governmental  functions”. 

C.  THE  CONTRACTING  ENVIRONMENT: 

1.  Excerpts  DoD  5000.1 

The  DoD  5000.1  document  specifically  addresses  Performance  -Based 
Acquisition  and  the  methods  and  practices  needed  to  support  that  type  of  acquisition.  The 
following  are  excerpts  from  DoD  5000.1  that  help  describe  the  expectation  and 
requirements  of  the  contracting  environment: 
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4.2.4  -  Performance-Based  Acquisition. 


In  order  to  maximize  competition,  innovation,  and  interoperability,  and  to 
enable  greater  flexibility  in  capitalizing  on  commercial  technologies  to 
reduce  costs,  perfonnance-based  strategies  for  the  acquisition  of  products 
and  services  shall  be  considered  and  used  whenever  practical.. 

4.3.3.  -  Competition. 

Competition  is  critical  for  providing  innovation,  product  quality,  and 
affordability.  All  DoD  Components  shall  acquire  systems,  subsystems, 
equipment,  supplies  and  services  in  accordance  with  the  statutory 
requirements  for  competition.  Competition  provides  major  incentives  to 
industry  and  Government  organizations  to  reduce  cost  and  increase 
quality.  The  Department  must  take  all  necessary  actions  to  promote  a 
competitive  environment,  including  examination  of  alternative  systems  to 
meet  stated  mission  needs;  structuring  Science  and  Technology 
investments  and  acquisition  strategies  to  ensure  the  availability  of 
competitive  suppliers  throughout  a  program’s  life  and  for  future 
programs... 

4.4.1.  -  Total  Systems  Approach. 

Acquisition  programs  shall  be  managed  to  optimize  total  system 
performance  and  minimize  total  ownership  costs  by  addressing  both  the 
equipment  and  the  human  part  of  the  total  system  equation,  through 
application  of  systems  engineering. . . 

4.4.2  -  Logistic  Transfonnation. 

Logistics  transformation  is  fundamental  to  acquisition  refonn.  Decision¬ 
makers  shall  take  all  appropriate  enabling  actions  to  integrate  acquisition 
and  logistics  to  ensure  a  superior  product  support  process.  The 
Department  shall  strive  for  an  integrated  acquisition  and  logistics  process 
characterized  by  constant  focus  on  total  cost  of  ownership;  supportability 
as  a  key  design  and  performance  factor;  logistics  emphasis  in  the  systems 
engineering  process;  and  that  meets  the  challenges  of  rapidly  evolving 
logistics  systems  supporting  joint  operational  forces. 

OMB  Circular  A-76  &  Supplemental  Handbook  defines  several  criteria,  which 
impact  the  PBL  contracting  environment.  The  following  are  excerpts  from  these 
documents: 
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Circular  A-76 


5.  Policy.. .a.  Achieve  Economy  and  Enhance  Productivity.  Competition 
enhances  quality,  economy,  and  productivity.  Whenever  commercial 
sector  perfonnance  of  a  Government  operated  commercial  activity  is 
pennissible,  in  accordance  with  this  Circular  and  its  Supplement, 
comparison  of  the  cost  of  contracting  and  the  cost  of  in-house 
performance  shall  be  performed  to  detennine  who  will  do  the  work. 
When  conducting  cost  comparisons,  agencies  must  ensure  that  all  costs  are 
considered  and  that  these  costs  are  realistic  and  fair. 

6.  Definitions ...■f.  A  cost  comparison  is  the  process  of  developing  an 
estimate  of  the  cost  of  Government  performance  of  a  commercial  activity 
and  comparing  it,  in  accordance  with  the  requirements  of  the  Supplement, 
to  the  cost  to  the  Government  for  contract  performance  of  the  activity. 

8.  Government  Performance  of  a  Commercial  Activity.. .d.  Lower  cost. 
Government  performance  of  a  commercial  activity  is  authorized  if  a  cost 
comparison  prepared  in  accordance  with  the  Supplement  demonstrates  that 
the  Government  is  operating  or  can  operate  the  activity  on  an  ongoing 
basis  at  an  estimated  lower  cost  than  a  qualified  commercial  source. 

Circular  A-76  Supplemental  Handbook 

Introduction . Circular  A-76  is  not  designed  to  simply  contract  out. 

Rather,  it  is  designed  to:  (1)  balance  the  interests  of  the  parties  to  make  or 
buy  cost  comparison,  (2)  provide  a  level  playing  field  between  public  and 
private  offerors  to  a  competition,  and  (3)  encourage  competition  and 
choice  in  the  management  and  performance  of  commercial 

activities . Reliable  cost  and  performance  information  is  crucial  to  the 

effective  management  of  Government  operations  and  to  the  conduct  of 
competitions  between  public  or  private  sector  offerors. 

Chapter  1  -  General  Provisions....C.  Government  Performance  of 
Commercial  Activities... 3.  Core  Capability.  -  A  minimum  core  capability 
of  specialized,  scientific  or  technical  in-house  or  contract  employees  and 
related  commercial  workload,  may  be  maintained,  without  cost 
comparison,  to  ensure  that  the  Government  has  the  necessary  capabilities 
to  fulfill  its  mission  responsibilities  or  meet  emergency  requirement. 

Government  Performance  of  Commercial  Activities...  7.  Meet 
Performance  Standard... a.  Performance  by  in-house,  contract  or  ISSA 
may  be  authorized  if  an  agency  demonstrated  that  performance  meets  or 
exceeds  generally  recognized  industry  perfonnance  and  cost  standards. 
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Government  Performance  of  Commercial  Activities...  8.  Lower  Cost.  -  In- 
house,  contract  or  ISSA  perfonnance  of  a  commercial  activity  may  be 
warranted  by  the  results  of  a  cost  comparison  conducted  in  accordance 
with  the  procedures  described  in  this  Supplement. 

G.  Review  of  Documents....  1.  Access  to  Supporting  Documentation.  -  a. 

At  the  earliest  possible  stages  of  development,  consistent  with 
procurement  and  conflict  of  interest  requirements,  affected  parties  will 
have  the  opportunity  to  fully  participate  in  the  development  of  supporting 
documents  and  proposals,  including  the  development  of  performance 
standards,  perfonnance  work  statements,  management  plans,  and  the 
development  of  in-house  and  contract  cost  estimates.  -  b.  Upon  issuance,  a 
solicitation  used  in  the  conduct  of  a  cost  comparison  will  be  made 
available  to  directly  affected  Federal  employees  or  their  representatives 
for  comment.  The  employees  or  their  representatives  will  be  given 
sufficient  time  to  review  the  document  and  submit  comments  before  final 
receipt  of  offers  from  the  private  sector. 

Chapter  3  -Cost  Comparisons... B.  The  Cost  Comparison  Study 
Team. ..1...  The  team  should  document  mission  requirements  and  seek 
new  and  innovative  ways  to  provide  the  required  products  or  services. . . . 

Chapter  3  -Cost  Comparisons... C.  Performance  Work  Statements...  1. 
Performance  Work  Statements  (PWS)  should  be  developed  for  all 
activities  being  resolicited  for  contract  or  scheduled  for  direct  conversion 

to  or  from  in-house,  contract  or  ISSA  perfonnance . 4.  Special  care 

should  be  taken  when  developing  the  PWS  to  ensure  that  it  does  not  limit 
service  options,  arbitrarily  increase  risk,  reduce  competition,  unnecessarily 
violate  industry  service  or  service  grouping  norms  or  omit  statutory  or 
regulatory  requirements  without  full  justification . 

2.  Summary 

The  DoD  5000  series  documents  require  the  contracting  environment  to  maximize 
competition  and  considers  it  critical  in  providing  innovation,  product  quality, 
affordability  and  reducing  costs  from  both  government  and  industry  providers  alike. 
Through  the  use  of  the  Systems  Engineering  approach,  an  integrated  acquisition  and 
logistic  process  must  focus  on  Total  Ownership  Cost  (TOC);  supportability  as  a  key 
design  and  performance  factor.  The  OMB  Circular  A-76  requires  through  policy 
statements,  the  use  of  competition  to  enhance  quality,  economy,  and  productivity.  These 
enhancements  are  possible  by  performing  cost  comparisons  of  commercial  activities 
performed  by  the  government,  with  contracted  commercial  activities  from  either  within 
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the  government  or  from  industry.  Circular  A-76  is  not  designed  to  simply  contract  out. 
Rather,  it  is  designed  to:  (1)  balance  the  interests  of  the  parties  to  make  or  buy  cost 
comparison,  (2)  provide  a  level  playing  field  between  public  and  private  offerors  to  a 
competition,  and  (3)  encourage  competition  and  choice  in  the  management  and 
performance  of  commercial  activities 

D.  PERFORMANCE  BASED  CONTRACTING  IMPLEMENTATION 

GUIDANCE  DOCUMENTATION: 

1.  Excerpts 

The  following  references  and  documents  are  considered  as  the  implementation 
guidance  set  of  documents  in  evaluating  the  Perfonnance  Based  Contracting  (PBC) 
requirements: 

•  Product  Support  Guide:  Product  Support  A  Program  Manager’s  Guide  to 

Buying  Performance  [6)  DUSD  L&MR] 

•  Perfonnance  Based  Logistics:  NAVICP  Fact  Sheet  [15)  NAVICP] 

•  Perfonnance  Based  Logistics  Business  Case  Analysis  (BCA)  [15)  NAVICP] 

The  following  are  excerpts  from  Product  Support  A  Program  Manager’s  Guide  to 
Buying  Perfonnance  and  are  chosen  because  the  excerpt  identifies  a  new  requirement  or 
a  further  refinement  of  higher  level  requirement  which  will  impact  implementation 
efforts 


1.3  Performance-Based  Logistics . PMs  will  implement  PBL  on  all  new 

systems  and  on  Acquisition  Category  I  and  II  fielded  systems  selected  on 
the  basis  of  a  sound  business  case . 

2.7  Developing  Program  Baseline  Performance  and  Cost . For  legacy 

systems,  the  Baseline  assessments  form  the  basis  for  business  case 
analysis  of  PBL  approaches  being  considered.  In  conducting  the  business 
case  analysis,  alternative  solutions  are  assessed  in  tenns  of  their  ability  to 
meet  the  logistics  performance  objectives  of  the  warfighters  compared 
particularly  to  existing  support  strategies. 

2.9  Establishing  a  Product  Support  Integration  Function.... A  concluding 
step  in  developing  a  product  support  strategy  is  establishing  a  product 
support  integrator  function.  As  with  the  PBL  strategy  and  the  agreement 
with  the  warfighter,  the  product  support  integration  function  is  a  key 
component  of  the  product  support  strategy  documented  in  the  acquisition 
strategy. 
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The  following  are  excerpts  from  -  NAVICP  Performance  Based  Logistics  Fact 
Sheet  and  are  chosen  because  the  excerpt  identifies  a  new  requirement  or  a  further 
refinement  of  higher  level  requirement  which  will  impact  implementation  efforts: 

Concept.... Under  the  PBL  program,  NAVICP  awards  a  contract  to  a 
single  supplier.... 

PBL  suppliers  may  take  on  a  number  of  functions  normally  performed  by 
various  Departments  of  Defense  (DoD)  services  or  agencies.... 

Arrangements  may  be  made  with  industry  partners  supporting 
commercially  available  equipment,  with  industry  partners  supporting 
military  unique  equipment,  government  activities  supporting  military 
unique  equipment  or  industry  partners  who  have  government  activities 
functioning  as  their  sub-vendors . 

Potential  candidates  can  be  broken  down  into  two  categories.  Category  I 
items  are  those  we  should  automatically  pursue  as  PBL  contracts. 
Category  II  items  are  those  we  should  consider  as  PBL  candidates . 

Category  I  Items  (automatic  PBL  candidates) :...c.  New  Items/Systems: 

These  are  items/systems  being  introduced  into  the  Navy/Marine  Corps. 

These  systems  are  very  early  in  their  life  cycle  and  are  at  a  point  where 
maximum  financial  benefit  can  be  derived  from  a  PBL.  An  early  PBL 
decision  can  avoid  costly  investment  in  test  equipment,  training,  Logistics 
Support  Analysis  (LSA)  development,  wholesale  spares  investment, 
etc . 

Category  II  Items  (possible  PBL  candidates):... Items/systems  not  covered 
under  Category  I  where  we  are  experiencing  difficulty  providing  adequate 

support  to  our  fleet  customers.  These  include . c.  Items  with  low  supply 

material  availability. . .  .e.  Items  with  parts  obsolescence  issues. . . . 

Business  Approach... For  each  PBL  initiative,  NAVICP  will  conduct  a 
Business  Case  Analysis  (BCA) . 

PBL  Categories. .  .The  following  categories  are  used  by  NAVICP  to 
describe  the  various  types  of  PBL  arrangements :...(  special  note  the  table 
with  specific  assigned  capabilities  or  services  is  presented  in  this  section 
along  with  description  of  each  category,  this  information  is  also  displayed 
in  the  body  of  the  text  of  this  Marketing  Plan). . . . 


422 


The  following  are  excerpts  from  -  NAVICP  Performance  Based  Logistics 
Business  Case  Analysis  (BCA)  Fact  Sheet  and  are  chosen  because  the  excerpt  identifies  a 
new  requirement  or  a  further  refinement  of  higher  level  requirement  which  will  impact 
implementation  efforts: 

For  each  PBL  initiative,  NAVICP  will  conduct  a  Business  Case  Analysis 
(BCA) . 

The  BCA  process  involves  determining  the  Navy’s  current  cost  of  doing 
business.  This  “without  PBL”  cost  is  then  compared  to  the  cost  to  the 
Navy  if  we  execute  a  PBL  arrangement.  This  “with  PBL”  cost  includes 
both  the  PBL  supplier’s  cost  as  well  as  residual  costs  the  Navy  will  retain 
even  under  a  PBL  arrangement. 

The  foundation  documents,  put  in  place  to  establish  the  performance  based 
contracting  methodology,  identify  this  cost  focus  as  the  primary  discriminating  criteria. 
The  guidance  documents,  used  to  implement  the  methods,  go  beyond  the  cost  criteria  by 
adding  additional  caveats  and  restrictions,  such  as  an  “all  or  nothing”  involvement,  for 
functionally  different  but  related  portions  of  the  support  effort.  Furthermore  by  dictating 
the  allocation  of  certain  functions  to  be  accomplished  by  specific  entities,  the  guidance 
documents  constrain  the  cost  focus  of  the  foundational  documents  potentially  yielding  to 
sub-optimal  results.  The  NAVICP  implementation  documents  defines  three  baseline 
assumptions  which  mold  the  contracting  environment:  1)  awards  a  contract  to  a  single 
supplier,  2)  assess  current  in-house  government  activities/functions  on  past  perfonnance 
only,  and  3)  defines  a  government  employee  and/or  activity  as  sub-contracting  to  a 
contractor.  The  singular  contract  requirement  cannot  be  implemented  within  the  Organic 
activities  due  to  built-in  constraints  defined  by  the  Navy’s  structure.  In  identifying  this  as 
a  pivotal  requirement  the  implementation  documents  define  a  non-competitive 
environment  with  respect  to  the  Organic  activities.  The  second  implemented  baseline 
assumption  provides  bias  when  perfonning  cost  comparisons.  Central  to  the  decision 
making  process  regarding  the  potential  use  of  a  Performance  Based  Logistics  (PBL) 
contract  is  the  development  of  the  Business  Case  Analysis  (BCA).  The  ground  rules 
currently  used  in  developing  the  baseline  cost  estimates  for  Organic  support  (i.e.  in-house 
Navy  support  activity)  uses  historical  performance  data  and  compares  this  data  with 
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contractor  proposed  estimates  in  evaluating  cost  effectiveness  of  the  contractor’s 
proposed  cost.  Important  to  notice  is  that  the  Organic  support  costs  rely  solely  on  the 
past  data  and  by  doing  the  analysis  in  this  manner  three  major  assumptions  are  made:  1) 
the  past  performance  data  is  accurate,  applied  in  an  appropriate  manner,  and  the  data 
reflects  current  and  future  performance  of  the  Organic  activities/functions,  2)  there  are  no 
opportunities  to  reduce,  streamline,  or  improve  the  Organic  cost  figures,  and  3)  the 
Organic  activities/functions  would  not  be  affected  by  the  competitive  environment. 
Applying  historical  costs  to  the  Organic  entities  and  comparing  the  cost  estimates  in  a 
proposal  from  the  contractor  yields  a  bias  in  favor  of  the  contractor.  Although  this  type 
of  analysis  is  considered  to  foster  a  competitive  environment  where  the  lowest  cost  gets 
the  contract,  the  process  side  steps  many  of  the  tenets  of  true  competition.  The  third 
baseline  assumption  appears  to  be  in  direct  conflict  with  the  foundational  documents  for 
functions/activities,  which  require  the  use  of  value  judgments  having  long-term 
programmatic  impacts.  The  implementation  methods  employed  in  developing 
performance  based  contracts  handicaps  the  Organic  activity/function,  identifies  no 
method  to  input  into  the  decision-making  criteria,  potentially  places  Government 
employees  in  a  position  of  having  a  “conflict  of  interest”,  provides  a  “non  level  playing 
field”,  and  in  no  way  assures  the  Navy  receives  the  best  possible  value  available  in 
today’s  market  place. 

2.  Conclusion:  The  Performance  Based  Contracting  Environment 

The  new  emphasis  in  the  contracting  environment  using  PBL  contracting 
methodologies  presents  challenges  to  the  Organic  activity/functions  with  respect  to 
implementing  the  SSB  system.  It  appears  evident  that  these  challenges  include:  1)  a 
barrier  to  entry  into  the  PBL  contracting  environment  due  to  exclusionary  policies  at  the 
contract  implementation  level  although  the  upper  level  policies  support  the  SSB  systems 
concepts,  2)  the  current  contracting  methodologies  establish  scenarios  in  which  there 
could  be  a  “conflict  of  interest”  for  Government  employees  when  providing  sub¬ 
contracting  services  for  a  contractor,  this  potential  could  directly  impact  the  SSB  system 
applicability  since  it  is  performed  by  Organic  activities/functions,  and  3)  no 
definition/designation  is  provided  with  regards  to  the  DMSMS  support  function  and  its 
categorization  as  an  “inherently  Governmental  function”  or  a  commercial  activity, 
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without  such  an  identification  there  exists  an  amount  of  uncertainty  about  who  would  be 
performing  the  SSB  systems  functions  in  the  future.  The  purpose  of  this  section  is  to 
identify  and  describe  the  factors,  which  could  influence  the  success  of  the  SSB  system  in 
the  current  market  place.  Responses,  adjustments,  and/or  resolution  to  the  challenges 
described  above  will  be  addressed  later  in  this  Marketing  Plan. 
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II.  THE  CUSTOMER  ENVIRONMENT 


A.  WHO  ARE  OUR  CURRENT  AND  POTENTIAL  CUSTOMERS? 

As  identified  in  the  external  environmental  analysis  our  current  customers  are  the 
Navy  programs  who  need  long-tenn  COTS  supportability.  Our  end  customer  is  the 
Program  Manager  (PM)  who  has  the  ultimate  responsibility  for  the  life  cycle 
supportability  for  fielded  products.  The  PM  in  managing  this  responsibility  delegates 
much  of  the  supportability  responsibilities  to  a  team  specifically  chartered  for  that 
purpose.  Although  the  type  of  team  can  take  many  forms  (i.e.  Integrated  Product 
Development,  working  group,  etc.),  the  methods,  practices,  and  processes  used  in 
supporting  the  long-term  supportability  strategy  is  a  team  product  and,  as  such,  the  actual 
using  customer  is  the  support  team.  The  support  team  is  a  cross  functional  group  of 
teaming  members  who  must  identify,  implement,  and  measure  the  effectiveness  of  the 
support  solution  alternatives.  The  PM  has  the  authority  and  power  to  direct  and  empower 
the  team  and  must  also  provide  adequate  resources  for  the  team  to  function.  Potential 
customers  include  other  entities  who  face  similar  requirements  and  constraints  as  our 
current  Navy  customer  base.  Provided  below  is  a  sample  list  if  prioritized  potential 
groups,  entities  or  functional  areas  under  consideration  for  extending  the  customer  base: 

1)  Military  Branch  Services: 

a.  Army,  Air  Force,  Special  Forces 

2)  Non-Military  Branch  Services: 

a.  Coast  Guard 

b.  Homeland  Defense  Support  Entities 

c.  Alphabet  Soup  of  Governmental  Entities:  FBI,  CIA,  NSA,  NASA,  DOE, 
NOAA,  USGS,  DARPA,  etc. 

3)  Industrial  Segment  using  COTS  such  as: 

a.  Aircraft  industry 

b.  Industrial  Machinery  (i.e.  Numerically  Controlled  Laths) 

c.  Fann  Equipment 

d.  Industrial  Production  Facilities  (i.e.  Assembly  plants,  petrochemical,  etc) 
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B.  WHAT  DO  OUR  CUSTOMERS  DO  WITH  OUR  PRODUCTS? 

The  service  we  provide  establishes  relationships  with  the  manufacturer  of  the 
COTS  products,  the  aftermarket  manufacturer  -  SSB  supplier,  the  supportability  planning 
team  and  the  procurement  functions.  The  customer  (i.e.  support  team)  will  embed  the 
SSB  system  within  the  overall  supportability  strategy,  then  task  us  to  implement  and 
monitor  the  effort.  The  long-term  supportability  planning  for  a  Navy  fielded  system 
requires  continuous  review  and  updating  through  inserting  new  technology  on  a  regular 
basis.  The  SSB  system  is  easily  adaptable  for  sequential  reuse  reducing  the  Life  Cycle 
Cost  (LCC)  of  the  Navy’s  fielded  systems. 

C.  WHERE  DO  OUR  CUSTOMERS  PURCHASE  OUR  PRODUCTS? 

As  with  many  professional  services,  our  service  satisfies  a  niche  requirement  for 
our  customers  accomplished  through  a  teaming  environment.  The  community  of  players 
-  PM,  the  support  team,  the  upper  level  support  organizational  structures  (i.e.  SYSCOMs, 
PEOs,  Field  Activities,  etc.)  -  are  all  potential  network  points  to  match  our  service  with 
the  customer  base.  Knowing  that  it  is  this  community  with  it’s  unstructured  network  that 
provides  the  primary  mechanism  through  which  our  services  get  requested,  it  becomes 
evident  that  it  is  not  so  much  the  place  that  holds  importance  (‘the  right  place  at  the  right 
time’)  but  instead  it  is  the  relationship  with  the  community  (networking)  that  places  our 
service  in  front  of  the  customers. 

D.  WHEN  DO  OUR  CUSTOMERS  PURCHASE  OUR  PRODUCTS? 

The  purchasing  of  our  services  are  situational  based,  in  that,  either  there  is  an 
immediate  threat  or  emergency  or  as  part  of  the  established  planning  process.  If  the 
services  are  in  response  to  an  immediate  threat  the  customers  procure  the  required 
amount  of  service  at  that  time  and  if  satisfied  will  usually  make  arrangements  to  retain 
services  for  future  issues.  If  our  services  are  purchased  as  part  of  the  established 
planning  processes  the  customer  will  request  a  proposal  for  services  for  the  next  Fiscal 
Year  (FY)  around  March/ April  time  frame  of  each  year.  Next  the  customer  will  work 
with  us  to  establish  a  Statement  of  Work  (SOW)  and  a  funding  profile  for  the  next  Fiscal 
Year  (FY)  budget  and  funding  process,  which  will  come  to  fruition  in  the  coming  new 
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FY  starting  in  October.  In  summary,  unplanned  services  can  be  procured  at  any  time  and 
planned  services  are  purchased  on  an  annual  basis  at  the  start  of  the  new  FY. 

E.  WHY  (AND  HOW)  DO  OUR  CUSTOMERS  SELECT  OUR  PRODUCTS? 

Our  services  are  unique  and  provide  attributes  not  found  through  any  other 
methods,  processes  or  services.  Our  customers  select  our  services  for  the  wide  range  of 
positive  characteristics  resulting  from  implementing  our  services,  some  of  the  major 
positive  aspects  include:  50%  reduction  in  Life  Cycle  Costs  (LCC)  as  compared  to  the 
typically  employed  methods,  substantial  reduction  in  supportability  risk  to  the  program, 
long-term  relationship  building,  long-term  business  planning  including  -  tech  refresh 
cycles,  Fleet  deployment  planning,  supporting  system  equipment  baselines,  and  inputs 
which  allow  stabilization  of  the  Planning,  Programming  and  Budgeting  System  (PPBS). 

F.  WHY  DO  POTENTIAL  CUSTOMERS  NOT  PURCHASE  OUR 

PRODUCTS? 

The  SSB  system  is  new  and  is  just  now  returning  the  kind  of  results  identified 
above.  Without  a  proven  track  record  many  would  be  customers  are  unwilling  to  take  the 
risk  and  embrace  the  system.  As  we  gain  more  implementation  experience,  the  risk  to 
our  customers  can  be  identified  in  a  more  concise  way  and  eventually  we  will  be  able  to 
win  over  some  of  these  skeptical  potential  customers.  Another  reason  for  potential 
customers  not  purchasing  our  services  is  because  of  the  Navy’s  contracting 
methodologies.  These  contracting  methods  exclude  our  participation  while  providing 
incentives  to  the  contractor  to  produce  less  optimal  support  systems.  The  SSB  system  is 
actually  accepted  or  rejected  by  a  support  team  and  as  described  under  the  “competitive 
environment”  section  of  this  plan,  there  are  a  host  of  reasons  why  such  a  team  would 
reject  the  SSB  system. 
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III.  INTERNAL  (ORGANIZATIONAL)  ENVIRONMENT 


A.  REVIEW  OF  THE  MISSION 

Our  mission  is  to  provide  our  customers  with  cost  effective  services  and  products, 
which  address  the  business,  technical,  and  management  issues  associated  with  the 
inherent  supportability  risks  of  COTS  products  in  fielded  systems. 

B.  REVIEW  OF  MARKETING  GOALS,  OBJECTIVES,  AND 

PERFORMANCE 

What  are  our  current  marketing  goals  and  objectives? 

The  marketing  objectives  involve  establishing  the  SSB  system  a  unique  standard 
practice  while  projecting  the  image  as  an  enabler  of  currently  used  support  systems  that 
are  employed  during  the  decision-making  processes  regarding  supportability  of  COTS 
products.  The  SSB  system  is  a  collaborative  system  in  which  the  participants  voluntarily 
use  the  system  and  in  return  receive  value  added  products  and  outputs.  Described 
another  way,  think  of  the  collaborative  process  much  in  the  same  way  you  would  think  of 
a  “Franchise”:  “Why  would  someone  join  and  why  would  they  chose  to  stay”.  One  of  the 
most  important  parameters  in  showing  the  utility  of  the  SSB  system  will  be  in  describing 
the  value-add  proposition  and  its  applicability  to  other  situations.  The  System 
Engineering  approach  provided  through  implementation  of  the  SSB  system  allows  us  (the 
Navy),  to  leverage  currently  used  methods  and  processes  and  yielding  more  robust  and 
cost  effective  support  systems.  The  projected  image  must  be  substantiated  with  “real 
life”  examples  of  the  value-added  proposition  results  and  this  Marketing  Plan  shall 
illustrate  these  characteristics.  Our  current  goal  of  20%  capture  of  the  Navy  programs 
translates  to  72  programs  or  an  equivalent  80  man-years  per  year  effort,  and  it  is 
estimated  that  this  quantity  of  programs  will  establish  the  SSB  system  as  one  of  the 
standard  solution  alternatives.  It  is  important  to  understand  that  the  SSB  system  is  one  of 
the  potential  solutions  to  a  given  solution  space  and  the  term  “capture”  refers  to  the 
programs  funding  of  an  analysis  to  evaluate  the  potential  in  implementing  the  SSB 
system  which  may  or  may  not  be  chosen  as  the  final  alternative.  In  essence  a  program 
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will  need  to  invest  in  the  relationship  building  portion  of  the  SSB  system  as  part  of  a 
trade-off  to  be  identified  as  being  ‘captured.’ 

Are  our  marketing  goals  and  objectives  consistent  with  the  mission,  goals,  and  objectives 
of  the  firm  (i.e.  Navy)?  Are  our  marketing  goals  and  objectives  consistent  with  recent 
changes  in  the  marketing  or  customer  environments? 

Unfortunately  the  answer  is  both  yes  and  no.  The  Navy  totally  supports  the 
value-added  proposition  and  the  measurable  results  captured  to  substantiate  it,  however 
some  of  the  contracting  policies  such  as  PBL  have  unintended  consequences  that  work  in 
a  counter  productive  way  to  this  support.  The  risk  management  methods,  processes,  and 
tools  implemented  through  the  SSB  system  were  not  available  when  the  counter 
productive  contracting  policies  and  practices  were  put  into  place.  The  inconsistencies 
identified  here  will  be  addressed  later  in  the  marketing  plan. 

How  are  our  current  marketing  strategies  performing  in  terms  of  sales  volume,  market 
share,  profitability  and  communication  (e.g.,  awareness  and  preference )  objectives? 

The  SSB  System’s  strategic  direction  for  marketing  is  that  of  Product  Leadership. 
Currently  the  SSB  system  is  the  only  system  developed  to  address  proactive  long-tenn 
COTS  supportability  without  the  reliance  on  specific  design  architecture.  There  exists 
some  proactive  design  architectures  such  as  “open  systems  architectures”  which  allow  for 
very  quick  change  out  of  one  COTS  item  for  another  without  major  design  changes. 
However  the  limitations  in  using  this  approach  is  that  it  must  be  instantiated  upfront  in 
the  design  of  the  system  and  the  approach  does  not  apply  to  all  possible  cases.  The  SSB 
system  has  unique  characteristics  that  allow  application  to  most  systems  independent  of 
design  and  allow  the  Program  Manager  (PM)  to  choose  the  length  of  support,  for 
example  length  of  time  between  tech  refreshes.  Using  this  Product  Leadership  strategy  in 
the  early  marketing  stages  we  have  captured  4  programs  or  .01%  of  all  programs  and  with 
respect  to  our  goal  of  72  programs  or  the  equivalent  of  5.5%  of  the  goal.  These  programs 
are  leading  edge  thinkers  identified  as  “innovators”  and  are  willing  to  take  the  risk  in 
using  a  new  and  novel  approach.  From  these  first  few  programs  we  have  gathered  the 
data  and  metrics  to  show  in  a  Business  Case  Analysis  (BCA)  the  value-added  proposition 
provided  by  the  system.  The  position  strategy  of  Product  Leader  may  always  be  part  of 
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the  SSB  system  marketing  approach,  however  once  the  20%  goal  is  reached  and  the 
system  is  considered  as  one  of  the  standard  methods,  competition  will  emerge,  such  that, 
in  order  to  grow  our  market  share  we  will  need  to  adjust.  The  strategic  direction  we 
believe  will  slowly  shift  from  Product  Leader  to  Customer  Intimacy  where  our 
personnel’s  direct  involvement  with  the  programs  and  the  continuous  name  recognition 
of  “SSB”  will  provide  a  branding  regarding  proactive  long-tenn  COTS  supportability. 
An  inherent  characteristic  of  the  SSB  system  is  that  the  more  inputs  or  business  added  to 
the  core  database,  the  greater  utility  the  system  becomes  at  solving  new  customers  issues. 
For  example  the  first  four  programs  had  only  a  few  COTS  configurations,  which 
overlapped  programs  or  OEMs.  The  next  programs  may  find  that  when  having  their 
COTS  configuration  list  checked  against  the  current  database  perhaps  we  will  see  a  10% 
overlap,  whereby  the  10%  represents  the  amount  of  work  that  has  already  been 
accomplished.  This  percent  overlap  will  continue  to  rise  as  workload  increases  over  time 
so  that  each  new  program  gains  leverage  from  all  previous  implemented  programs.  The 
more  the  Navy  uses  the  SSB  system  the  more  there  is  to  be  gained  by  the  Navy  in  both 
short  and  long-term  support  of  its  programs.  As  part  of  the  initial  System  Architecture 
the  SSB  system  is  structured  to  perfonn  many  of  its  data  review  and  evaluations  using 
computer  programs  to  accomplish  these  repetitive  time  consuming  task  then 
automatically  generate  a  menu  driven  reporting  system.  For  the  first  few  programs  the 
data  manipulation,  review,  evaluation,  and  reporting  functions  were  accomplished  by 
hand,  although  a  computer  program  is  being  developed  based  on  this  initial  data  input. 
This  automation  combined  with  the  expected  growth  of  the  system  will  produce 
efficiencies  that  may  allow  us  to  pursue  a  marketing  strategy  of  Operational  Excellence. 
This  type  of  strategy  may  be  reviewed  only  after  the  computer  based  system  is  mature 
and  the  market  forces  are  requiring  us  to  change  our  strategic  approach.  Using  our  initial 
strategy  as  a  Product  Leader  the  response  from  our  potential  customer  base  has  been 
outstanding.  Several  calls  each  week  for  more  information  and  request  for  proposals, 
have  been  coming  in  at  a  constant  rate.  The  draw  seems  to  be  the  novel  approach  in  an 
area  with  no  or  few  other  choices.  The  method  of  communication  yielding  this  type  of 
response  is  a  product  of  two  different  delivery  methods:  conference  presentations  and 
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word  of  mouth.  The  split  between  the  two  types  is  about  40/60  -  conference 
presentations  to  word  of  mouth. 

How  does  our  current  performance  compare  to  other  firms  in  the  industry?  Is  the 
performance  of  the  industry  as  a  whole  improving  or  declining?  Why? 

The  entire  industry  catering  to  the  DMSMS  market  is  in  a  growth  mode  partially 
due  to  the  increased  content  of  COTS  products  in  the  fielded  DoD  systems  and  also  due 
to  the  life  extension  to  many  of  the  major  combat  weapon  systems.  The  interest  in  our 
products  and  services  appears  to  have  a  larger  increase  with  other  players  in  the  industry 
than  the  Organic  participants.  We  believe  that  this  is  primarily  due  to  the  unique 
attributes  of  our  services  and  products  because  the  type  of  inquires  we  have  received  thus 
far. 

If  our  performance  is  improving,  what  actions  can  we  take  to  ensure  that  our 
performance  continues  to  improve?  Is  the  improvement  in  performance  due  to  a  better 
than  anticipated  environment  or  superior  planning  and  implementation? 

The  next  phase  of  our  System  Engineering  Development  and  Implementation 
(SEDI)  Plan  is  to  publish  the  results  of  the  first  3  programs  implementation  results.  This 
phase,  as  planned,  is  currently  underway  and  results  will  be  released  concurrent  with  the 
release  of  this  Marketing  Plan.  The  impact  to  the  marketing  effort  will  be  significant 
because  the  Business  Case  Analysis  (BCA),  using  real  data,  has  shown  the  benefit  to  the 
program  accompanied  by  a  well  defined  path  for  implementation.  The  SSB  system  will 
sell  itself  on  its  own  merits  if  given  a  fair  and  open  competitive  environment.  We  have 
already  received  requests  from  several  program  representatives  to  let  them  know 
immediately  where  they  could  get  the  data  once  released.  Continuous  reporting  on  initial 
performance  will  further  improve  our  market  position.  Continuous  improvements  are 
expected  because,  they  were  driven  by  design,  structure,  planning,  and  feedback  from  the 
implementation  efforts. 

C.  REVIEW  OF  CURRENT  AND  ANTICIPATED  RESOURCES 

What  is  the  state  of  our  current  organizational  resources  (e.g.,  financial,  capital,  human, 
experience,  relationships  with  key  suppliers  or  customers)?  Are  these  resources  likely  to 
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change  for  the  better  or  worse  in  the  near  future?  If  the  changes  are  for  the  better,  how 
can  we  utilize  these  added  resources  to  our  advantage  in  meeting  customer  needs  better 
than  competitors  ? 

The  SSB  system  as  currently  implemented  is  a  pay-as-you-go  type  financial 
arrangement.  A  program  is  solicited  that  has  an  immediate  need  for  support  appropriate 
to  the  SSB  system’s  attributes.  The  funding  is  then  allocated  by  the  program  for  the  SSB 
support  for  the  next  Fiscal  Year  (FY),  if  the  need  arises  mid  year  the  programs  have  short 
tenn  funding  mechanisms  to  receive  help  immediately.  Although  the  SSB  system  is 
capable  of  helping  in  the  short  term  the  strategic  focus  and  use  of  the  system  is  long-tenn 
support,  therefore  short  term  projects  are  looked  at  as  a  marketing  tool,  in  that  we  are  able 
to  “get  our  foot  in  the  door”  to  demonstrate  the  utility  of  the  system.  The  capital  needed 
to  provide  our  services  is  minimal,  a  server  and  work  stations,  and  most  are  already  in 
place  and  local  management  allocate  these  resources  to  the  SSB  effort  with  the 
expectation  of  growing  the  business.  There  are  two  primary  resources  needed  for  support 
and  growth  of  the  SSB  efforts:  experienced  personnel  and  development  of  close 
relationships  with  the  supply  base  (OEMs  and  SSB  suppliers).  The  SEDI  plan  was 
conceived  and  implemented  with  the  idea  of  using  the  implementation  efforts  as  a 
training  mechanism  to  provide  on-the-job  (OJT)  for  existing  personnel  resources  to 
expand  their  experience  base  to  include  the  SSB  system’s  methods,  processes,  and  tools. 
Currently  there  are  five  experienced  engineers  already  capable  of  implementing  the  SSB 
system  and  four  more  slated  for  training.  Additionally  the  SEDI  plan  has  been  prepared 
to  be  used  as  a  prescriptive  document  in  which  a  senior  engineer  could  take  the 
information  and  by  applying  the  appropriate  skills,  implement  the  SSB  system  with  some 
trial  and  error  efforts.  Even  if  independent  implementation  efforts  are  initiated,  central  to 
the  success  of  the  efforts  will  be  the  leverage  available  from  previous  work.  The 
database  that  was  established  for  the  SSB  system  contains  valuable  information  that, 
when  used  will  lessen  the  work  load  for  a  new  program  implementation  effort  and 
provide  a  track  record  of  success  to  “springboard’  the  new  effort.  Captured  within  the 
database  are  the  established  relationships  that  have  been  set  up  with  the  supply  base, 
described  either  to  the  level  identifying  the  suppliers  or  further  delineating  the  exact 
configuration  item  already  analyzed  in  support  of  another  program.  Initially  no 
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information  existed  but  after  implementing  on  just  four  programs  over  40  supplier 
relationships  have  been  defined  and  the  individual  number  of  configurations  covers  over 
130.  It  is  expected  on  the  next  program  about  10%  of  the  existing  data  will  be  reusable 
and  the  following  added  program  will  benefit  by  as  much  as  15%  reuse.  Eventually  a 
new  program  added  to  the  existing  database  may  have  as  much  as,  50%  coverage  due  to 
reuse.  Following  this  logical  progression,  it  is  clear  to  see  that  the  more  the  Navy  uses 
the  SSB  system  the  more  leverage  it  gains  and  that  additional  usage  will  provide  even 
greater  utility  through  use  of  the  system. 

D.  REVIEW  OF  CURRENT  AND  ANTICIPATED  CULTURAL  AND 

STRUCTURAL  ISSUES 

What  are  the  positive  and  negative  aspects  of  the  current  and  anticipated  culture  of  the 
firm  ? 

The  Navy  as  compared  to  other  branch  services  is  most  willing  to  allow  a  new 
idea  on  the  basis  that  the  oversight  rules  and  regulations  do  not  restrict  it,  whereas  other 
service  branches  take  the  approach  that  unless  the  rules  and  regulations  specifically  allow 
the  addition  of  a  new  idea  then  it  is  not  allowed.  This  allowance  of  the  Navy  to 
experiment  with  new  ideas  provides  an  excellent  environment  to  initiate  the  SSB  system. 
However  notwithstanding  this  freedom  the  Navy  Program  Management  Offices  (PMO) 
are  conservative  and  have  a  tendency  to  lean  on  past  experience  with  available 
products/processes  instead  of  jumping  on  a  new  way  to  do  business.  The  two  factors  that 
seem  to  be  the  deciding  factors  for  the  PMOs  is  impact  on  the  bottom  line  and  the 
reduction  of  risk  to  the  program.  The  SSB  system  excels  at  influencing  both  of  these 
factors  and  therefore  the  culture  works  in  our  favor. 

What  issues  related  to  internal  politics  and  power  struggles  might  affect  our  marketing 
activities? 

The  single  largest  issue,  as  identified  above,  is  the  position  NAVICP  has  taken 
with  their  contracting  policies  that  excludes  Organic  activities  from  providing  DMSMS 
support  in  the  primary  contracting  method,  PBL.  Without  the  support  of  NAVICP  in 
allowing  the  SSB  system  (an  Organic  function  accomplished  by  an  Organic  activity)  does 
not  keep  the  SSB  system  from  being  implemented  but  will  require  SSB  system  to  be 
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marketed  to  the  individual  PMO  organizations.  Conversely,  if  NAVICP  endorsed  the  use 
of  the  SSB  system  they  could  use  their  centralized  position  in  the  Navy  as  an  effective 
advertisement  method  to  enable  the  SSB  efforts.  The  marketing  situation  as  it  is 
currently  will  necessitate  us  to  approach  each  of  the  365  different  PMOs  with  the  SSB 
potential  so  that  at  the  PMOs  direction  NAVICP  must  not  contract  away  the  DMSMS 
functions.  Although  this  last  alternative  is  the  least  attractive  it  may  be  the  only  method 
to  implement  the  SSB  system  within  the  current  Navy  structure. 

What  is  the  overall  position  and  importance  of  the  marketing  function  as  seen  by  other 
functional  areas? 

In  the  DoD  environment,  marketing  functions  are  relatively  new  and  are  looked 
upon  with  skepticism  and  mistrust.  Historically  the  marketing  duties  were  additional 
duties  accomplished  by  the  upper  level  management  in  the  typical  personal  marketing 
approach.  Over  the  past  few  years  (e.g.,  5-10  years)  independent  non-coordinated 
marketing  endeavors  attempted  to  promote  certain  Organic  activities  and/or  functions. 
However  at  the  working  level,  in  many  cases  the  decision  level,  modern  marketing 
methods  and  practices  are  usually  frowned  upon  and  instead  the  personal  contacts, 
political  affiliations,  the  reputation,  past  involvement,  and  past  performance  are  the 
preferred  credentials  to  be  used  as  marketing  approaches.  It  is  important  to  understand 
this  mindset  when  developing  a  marketing  plan  so  that  in  introducing  new  marketing 
practices,  they  should  be  blended  with  at  least  some  of  the  acceptance  criteria  required  by 
the  focus  audience. 

Are  key  executive  positions  expected  to  change  in  the  future? 

The  Navy  like  all  the  other  branch  services  has  as  a  normal  turn  over  in  top 
military  management  approximately  every  2  years  and  depending  on  the  upper  level 
policies,  economic  environment,  and  top  level  strategies  the  impact  of  the  change  will 
depend  on  the  new  management  and  their  agenda.  The  Federal  Civil  Servant 
management,  on  the  other  hand,  is  typically  long  lived  and  maintains  the  corporate 
knowledge  and  know-how  to  enable  the  PMO  function.  There  seems  to  be  no 
expectations  of  change  at  the  civilian  management  levels  that  would  be  key  in  impacting 
the  SSB  system,  however  the  current  downsizing  efforts  at  the  upper  level  PMO  located 
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in  the  central  office  in  the  D.C  area  may  have  a  dramatic  affect.  This  downsizing  could 
bring  about  two  different  impacts  to  the  SSB  system  efforts:  1)  acquiesce  to  the  NAVICP 
PBL  implementation  plans  since  it  is  an  easy  path  to  offload  the  work  that  the  PMOs  no 
longer  have  the  staff  to  handle,  or  2)  be  more  open  to  allowing  a  new  method  used  by  an 
Organic  activity  to  perform  functions  previously  held  by  PMO  personnel,  keeping  the 
function  in-house  although  at  a  distance. 

How  will  the  overall  customer  orientation  of  the  firm  (or  lack  thereof)  affect  our 
marketing  activities  ? 

As  described  earlier,  the  using  customers  are  the  PMO  support  teams  and  the 
metrics,  which  guide  their  decisions  are,  by  design,  in  alignment  with  the  goals, 
objectives,  and  attributes  provided  through  the  use  of  the  SSB  system.  The  positive 
impact  the  SSB  system  will  have  on  Life  Cycle  Cost  (LCC)  and  obsolescence  risk 
reductions  will  open  the  door  for  our  marketing  activities. 

Does  the  firm  emphasize  a  long-term  or  short-term  planning  horizon? 

Although  the  Navy  in  general  emphasizes  long-term  relationships  and  planning 
horizons,  the  way  in  which  these  long-term  attributes  are  assessed  uses  short-term 
metrics,  such  as  the  funding  and  manning  level  goals  of  the  current  year  and  cutting  or 
curtailing  functions  to  meet  this  FY  goals  with  little  regard  for  impact  on  future  years. 
Since  the  SSB  system  provides  the  best  bottom  line  for  the  current  year  along  with  the 
long-term  horizon  optimization  both  end  effect  and  immediate  needs  can  be  met. 

How  will  this  emphasis  affect  our  marketing  activities? 

The  Business  Case  Analysis  (BCA)  should  take  center  stage  when  introducing  the 
SSB  system’s  concepts  so  as  to  open  the  door  for  other  marketing  opportunities.  Over 
time  the  track  record  on  successful  implementations  and  documented  customer 
satisfaction  will  add  some  assurances  to  the  PMO  regarding  the  perceived  risk  of 
implementing  the  SSB  system. 

Currently,  are  there  positive  or  negative  issues  with  respect  to  motivating  our  employees, 
especially  those  in  customer  contact  positions  (e.g.,  sales,  customer  service)? 
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Currently  the  SSB  system  implementation  efforts  are  carried  out  in  an  Integrated 
Product  Teaming  (IPT)  environment,  which  has  fostered  a  sense  of  ownership  and 
interest  with  the  employees.  Every  employee  knows  that  by  implementing  the  SSB 
system  they  are  helping  solve  one  of  the  largest,  most  costly  problems  with  the  fielded 
systems.  Motivation  among  the  employees  is  high  at  this  initial  introduction  level  but 
over  time  it  is  expected  that  as  the  effort  appears  to  become  more  of  a  day-to-day  job 
instead  of  this  great  opportunity  and  challenge,  that  motivation  may  be  a  future  problem. 
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IV.  SWOT  ANALYSIS  FOR  THE  SSB  SYSTEM 


A.  STRENGTHS 

Strength  1:  The  SSB  system  provides  expandable,  transportable  and  Life 

Cycle  Cost  (LCC)  reducing  processes,  methods,  and  tools. 

How  does  this  strength  assist  in  meeting  customer  need? 

The  expandable  characteristic  of  the  SSB  system  allows  it  to  be  applicable  to 
most  any  program  regardless  of  size.  This  scalability  ensures  that  the  SSB  system  will  be 
able  to  keep  pace  with  a  program’s  growth  and  the  addition  of  other  COTS  products  as 
the  program’s  system  is  modernized.  The  transportability  feature  addresses  the  issue  of 
long-term  support  of  the  SSB  system  itself  so  if  it  was  no  longer  viable  to  receive 
services  from  the  current  Organic  activity  providing  the  service  then  at  the  program’s 
option  the  support  function  could  be  moved  to  another  activity.  Simply  stated  this  feature 
assures  the  longevity  of  the  SSB  systems  support.  The  LCC  reductions  possible  due  to 
the  implementation  of  the  SSB  system  is  the  strongest  driver  or  draw  by  the  PMO  for  the 
SSB  system  being  employed.  These  reductions  are  one  of  the  most  unique  characteristics 
of  the  SSB  system  and  a  clear  differentiating  attribute  which  impacts  one  of  the  most 
prominent  metrics  the  PMO’s  success  is  judged  against,  Life  Cycle  Cost.  The 
documented  processes,  methods,  and  tools  provide  assurances  to  the  customer  that  the 
service  received  through  implementing  the  SSB  system  is  repeatable,  continuous,  and 
reliable.  These  documented  practices  have  been  delineated  in  the  Systems  Engineering 
Development  and  Implementation  (SEDI)  Plan  with  detailed  examples,  instructions, 
templates,  processes,  etc.  which  can  be  immediately  implemented. 

How  does  this  strength  compare  to  our  competitor’ s  strengths?  Does  this  Strength  make 
us  different  from  (better  than)  our  competitors  in  the  minds  of  our  customers? 

The  SSB  system  provides  an  additional  alternative  to  the  PMOs  in  resolving 
obsolescence  issues,  however  it  differs  from  the  dozen  or  so  point  solutions  currently 
available  in  three  distinct  ways:  1)  the  collaborative  architecture  necessitates  the  use  of 
close  partnerships  with  the  supply  base  and  includes  these  entities  in  the  resolution 
process  and  in  the  business  planning,  2)  the  Systems  Engineering  approach  embedded 
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within  the  SSB  system  optimizes  on  the  LCC  and  long-term  support  providing  a  structure 
spanning  all  functional  disciplines  life  cycle  elements  -  this  allows  other  point  solutions 
to  be  incorporated  where  appropriate  to  achieve  maximum  utility,  and  3)  the  SSB  system 
when  used  at  the  appropriate  time  yields  the  lowest  LCC  and  best  value  risk  management 
process  for  COTS  products.  All  three  of  these  attributes  impact  the  program’s  ability  to 
provide  long-tenn  support  of  COTS  products  and  are  reflected  in  the  evaluation  criteria 
used  in  assessing  the  PMO’s  accomplishments,  as  viewed  from  their  sponsors. 

Strength  2:  The  SSB  system  provides  new  supportability  options  to  the 

PMOs. 

How  does  this  strength  assist  in  meeting  customer  need? 

The  SSB  system  reduces  the  amount  of  program  investment,  extends  the 
repair/depot  support,  and  establishes  methods  to  reduce  the  mean  logistic  delay  time  for 
supplier  supported  COTS  products.  The  investment  the  program  would  need  to  make  to 
cover  the  spares  required  over  the  supportability  period  will  be  drastically  different  when 
using  the  SSB  system’s  methods  and  processes,  as  compared  to  usual  method  of  support 
of  Life  Time  Buy  (LTB)  option.  As  an  example,  consider  a  $6,000.00  COTS  assembly 
used  in  the  fielded  systems  which  requires  100  spares  to  be  bought  for  life  cycle  support 
of  10  years.  This  particular  assembly  is  going  obsolete  due  to  two  chips  on  the  assembly 
with  a  total  cost  of  $200.00  per  assembly.  Without  the  SSB  system  and  using  the  LTB 
option  instead,  the  immediate  cost  to  the  program  would  be  ($6,000.00)*(100)  or 
$600,000.00.  Conversely  by  employing  the  SSB  system  the  resulting  immediate  cost  to 
support  the  program  would  be  ($200.00)*(100)  or  $20,000.00  +  Non-Reoccurring 
Engineering  Cost  (if  applicable.)  When  an  aggregate  of  cost  over  all  COTS  products  on  a 
given  program/system  is  rolled  up,  to  quantify  the  immediate  cost  to  the  program  the 
amount  is  usually  staggering.  The  SSB  system  support  allows  the  PMO  to  meet 
budgetary  constraints  while  providing  long-term  supportability  requirements.  The  close 
partnership  with  the  supply  base  provides  insight  into  not  only  the  obsolescence  issues 
but  also  gives  the  Navy  the  chance  to  negotiate  for  long-term  supplier  support  of  fielded 
products  for  repair  and  maintenance.  The  experience  gained  during  the  implementation 
of  the  SSB  system  on  three  programs  showed  that  every  SSB  participant  was  capable  and 
willing  to  perform  these  needed  depot  functions.  The  relationship  building  accomplished 
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as  part  of  the  SSB  implementation  process  also  addressed  another  Fleet  need  that  the 
suppliers  would  be  capable  and  willing  to  help  with  which  is  quick  turnaround  times  for 
field  returns.  Many  of  the  suppliers  are  willing  to  keep  a  spare  COTS  item  on  their  shelf 
to  replace  immediately  a  Fleet  returned  unit,  this  could  bring  the  turnaround  time  to  days 
instead  of  weeks  or  months. 

How  does  this  strength  compare  to  our  competitor’ s  strengths?  Does  this  Strength  make 
us  different  from  (better  than)  our  competitors  in  the  minds  of  our  customers? 

The  SSB  system  is  the  only  alternative  that  institutionalizes  the  Navy-supplier 
partnerships  through  a  well  defined  infrastructure  and  set  of  implementation  tools.  As 
part  of  the  process  the  PMO  (customer)  defines  the  supportability  boundary  criteria  such 
as  how  many  years  does  the  fielded  system  require  support  till  the  next  tech  refresh 
activity.  Only  the  SSB  system  allows  the  customer  to  choose  the  length  of  support 
desired,  all  other  support  methods  are  reactive  and  as  such  require  the  program  to  react 
with  a  point  solution  constraining  the  possible  alternatives  and  associated  time  elements. 
The  structures  set  in  place  by  the  SSB  system  provides  additional  opportunities  for  the 
PMO  to  perform  business  planning  such  as  PPBS,  funding  allocations,  and  equipment 
install  scheduling.  The  System  Engineering  approach  inherent  in  the  SSB  system 
provides  these  added  benefits,  which  are  not  available  through  the  use  of  point  solutions. 

Strength  3:  The  SSB  system  provides  a  proactive  COTS  obsolescence  risk 

management  process. 

How  does  this  strength  assist  in  meeting  customer  need? 

The  customer  has  a  need  to  support  fielded  systems  for  extended  periods  of  no 
less  than  5  years  but  support  could  be  required  up  to  15-20  years.  Since  COTS  products 
generally  have  life  spans  of  2-5  years  after  which  supportability  is  not  an  option  without 
some  type  of  intervention.  The  SSB  system  is  a  planned  intervention  that  is  based  on  the 
support  needs  as  identified  by  the  customer.  The  partnering  and  infonnation  sharing 
between  the  supply  base  and  the  Navy,  provides  insight  to  previously  undisclosed 
potential  obsolescence  risks  of  COTS  products.  Combining  this  new  knowledge  with  the 
SSB  infrastructures  yields  the  risk  management  methods,  processes,  and  tools  for  use  by 
the  PMO  to  proactively  address  the  inherent  COTS  risk  issues. 
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How  does  this  strength  compare  to  our  competitor’s  strengths?  Does  this  Strength  make 
us  different  from  (better  than)  our  competitors  in  the  minds  of  our  customers? 

The  SSB  system  was  specifically  designed  to  be  the  first  alternative  containing 
architectural  elements  capable  of  addressing  the  risk  issues  involved  with  COTS 
products.  The  key  to  success  in  managing  this  risk  is  the  use  of  a  systemic,  broad  based, 
life  cycle  approach  to  deal  with  the  entire  fielded  system.  These  key  elements  are  absent 
when  using  the  point  solution  approach  employed  by  the  other  alternatives.  The  SSB 
system  is  the  only  practice,  known  to  the  authors,  which  provides  opportunities  to  the 
customer  to  address  risks  previously  identified  as  large  and  open-ended  programmatic 
risks. 

Strength  4:  The  SSB  system  provides  the  infrastructure  to  enable  Business 
planning  and  Management  system  for  fielded  system  containing  COTS 
products. 

How  does  this  strength  assist  in  meeting  customer  need? 

Management  of  fielded  systems  containing  COTS  products  has  historically  been  a 
very  difficult  and  unsuccessful  venture  for  PMOs.  Several  characteristics  of  the  COTS 
products  compound  the  management  efforts  and  make  it  exceedingly  difficult  to  maintain 
control  over  these  products,  the  major  exacerbating  attributes  are:  1)  the  OEM  controls 
the  configuration  of  the  product  and  may  change  it  without  notice,  2)  the  rate  of  change 
of  the  COTS  products  is  measured  in  months  (i.e.  <  18-24  months  product  life  cycle) 
whereas  Fleet  installation  is  measured  in  years,  and  3)  many  COTS  products  do  not  have 
long-term  support  available.  The  SSB  system  was  specifically  designed  to  address  these 
issues  -  “head  on”  -  with  methods  to  gain  the  configuration  knowledge  and  potentially 
freeze  that  configuration  if  needed,  and  finally  the  issue  of  long-tenn  support  and 
obsolescence  management  is  addressed  through  processes  and  tools  embedded  within  the 
system.  As  an  emergent  new  property  of  the  SSB  system  due  to  the  long-term  planning 
and  holistic  view  taken,  the  knowledge  gained  regarding  the  fielded  system  identifies  the 
input  data  necessary  to  perform  long-term  business  planning  such  as:  estimated  spares 
required  each  year  of  support,  an  estimated  dollar  value  needed  each  year  to  extend  the 
COTS  life  cycle,  the  total  amount  of  proposed  budgetary  requirements.  The  SSB  system 


444 


provides  the  first  system,  which  yields  this  type  of  knowledge  that  is  based  on  justifiable 
detailed  information  used  in  predicting  the  estimates. 

How  does  this  strength  compare  to  our  competitor’ s  strengths?  Does  this  Strength  make 
us  different  from  (better  than)  our  competitors  in  the  minds  of  our  customers? 

With  the  designed-in  and  emergent  properties  of  the  SSB  system  the  PMO 
(customer)  can  now  control,  manage,  and  plan  the  physical  support  of  the  hardware  along 
with  the  business  support  (i.e.  the  PPBS,  resource  allocations).  No  point  solution 
alternatives  can  produce  these  systemic  characteristics  and  the  PMOs  have  been 
requesting  such  a  solution  with  no  implementable  practices  identified  until  the  SSB 
system  was  introduced. 

B.  WEAKNESSES 

Weakness  1:  The  SSB  system  is  a  new  system  with  a  very  small  track  record. 

How  does  this  weakness  hinder  us  in  meeting  customer  needs? 

The  first  issue  that  emerges  due  to  this  low  level  of  implementation  of  the  SSB 
system  is  a  concern  that,  regardless  of  the  outcome  of  the  first  implementation  efforts,  has 
the  system  been  adequately  tested  out  and  found  capable  for  every  or  most  every 
application.  Like  any  new  system  -  performance  over  time  -  will  be  the  arbitrator  for  the 
inclusion  and  growth  of  the  SSB  system.  The  lack  of  long  standing  track  record  will 
impact  the  acceptance  of  the  system  by  well  established  support  teams,  who  are  typically 
conservative  and  slow  to  incorporate  new  approaches. 

How  does  this  weakness  compare  to  our  competitors’  weaknesses?  Does  the  weakness 
make  us  different  from  (worse  than)  our  competitors  in  the  minds  of  our  customers? 

Although  the  point  solution  alternatives  lack  many  desirable  characteristics 
obtained  through  the  use  of  the  SSB  system,  the  point  solutions  have  been  used  to  support 
the  existing  fielded  systems  and  therefore  have  a  proven  track  record  and  an  expected 
outcome.  A  PMO  or  their  support  team  will  need  to  perfonn  a  trade-off  analysis  with 
regards  to  comparing  existing  methods  and  solution  alternatives  with  the  SSB  system’s 
attributes.  Depending  on  what  criteria  is  used  and  who  is  making  the  decisions,  the  SSB 
system  may  or  may  not  be  considered  as  a  potential  alternative.  Possible  roadblocks  and 
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constraints  are  described  in  the  “Competitive  Forces”  section  of  this  plan  and  provide 
insights  to  the  motivation  behind  some  group  or  person  wanting  to  exploit  this  weakness. 

Weakness  2:  The  SSB  system  necessitates  the  up-front  PMO  support  and  a 

long-term  commitment  on  behalf  of  the  PMO  and  the  support  team. 

How  does  this  weakness  hinder  us  in  meeting  customer  needs? 

The  SSB  system  is  built  on  a  collaborative  architecture  that  necessitates  the 
voluntarily  participation  of  its  members.  As  with  most  proactive  methodologies  the  SSB 
system  requires  some  up-front  investment  to  initiate  any  kind  of  return.  Typically  before 
the  PMO  will  invest  in  a  potential  alternative  they  will  want  to  know  what  kind  of  return 
can  be  expected  and  what  kind  of  risk  they  are  taking.  Compared  to  point  solution 
alternatives,  which  are  usually  singular  events,  the  SSB  system  requires  continuous 
support  over  the  life  cycle  of  the  fielded  COTS  products,  in  essence  locking  the  PMO 
into  a  long-tenn  commitment.  Both  the  up-front  support  and  the  long-term  commitment 
present  the  PMO  with  a  potential  risk  to  the  program  with  respect  to  funding  and 
technical  support  issues. 

How  does  this  weakness  compare  to  our  competitors’  weaknesses?  Does  the  weakness 
make  us  different  from  (worse  than)  our  competitors  in  the  minds  of  our  customers? 

The  PMO  or  their  support  team  will  need  to  perform  a  trade-off  study,  formally  or 
informally,  to  identify  the  cost-benefit  comparison  in  using  or  not  using  the  SSB  system 
on  their  specific  program.  The  approach  taken  in  performing  the  trade-off  study  will  be 
reflective  of  the  outcome.  If  the  approach  focuses  mostly  on  the  short-term  results  with 
little  attention  paid  to  the  long-tenn  outcome,  then  a  point  solution  alternative  may  look 
the  most  promising.  However  if  the  long-term  view  is  taken  and  the  focus  is  on  LCC  and 
reducing  programmatic  risk  the  most  probable  outcome  will  be  implementing  the  SSB 
system. 

Weakness  3:  The  SSB  system  is  not  part  of  the  mainstream  contracting 

process  implemented  by  NAVICP. 

How  does  this  weakness  hinder  us  in  meeting  customer  needs? 

When  a  PMO  tasks  NAVICP  to  contract  for  the  program  support  functions,  any 
Organic  activity  providing  DMSMS/obsolescence  support  functions  are  specifically 


446 


excluded  from  participating  in  the  contracting  process  —  this  exclusionary  policy  includes 
the  SSB  system.  Unless  the  PMO  has  an  awareness  of  the  situation  and  interjects  the 
desire  to  pursue  the  SSB  system  specifically,  the  SSB  system  will  not  even  receive 
consideration  as  a  possible  alternative.  As  identified  earlier  under  the  section  labeled  - 
“The  Performance  Based  Contracting  Environment”  -  the  implementation  policies  and 
guidelines  imposed  by  NAVICP  do  not  allow  a  competitive  environment  with  a  level 
playing  field  and  constrain  Organic  activities  potential  involvement  to  one  in  which 
places  the  government  employee  in  a  “conflict  of  interest”  position.  These  exclusionary 
policies  directly  hinder  the  PMO  access  to  the  SSB  system  and  provide  a  contracting 
situation  in  which  the  Navy  does  not  have  the  potential  to  receive  the  “best  value”  for 
services  under  contract. 

How  does  this  weakness  compare  to  our  competitors’  weaknesses?  Does  the  weakness 
make  us  different  from  (worse  than)  our  competitors  in  the  minds  of  our  customers? 

In  the  analysis  thus  far,  various  solution  alternatives  were  compared  to  each  other 
in  competing  for  resources,  however  with  the  exclusion  of  all  potential  alternatives 
except  as  deemed  appropriate  by  NAVICP  the  situation  shifts  the  argument.  If  the  PMO 
tasks  NAVICP  to  contract  for  the  support  functions,  no  competitive  environment  exists 
and  no  consideration  can  be  made  by  the  PMO  regarding  the  utility  and  cost  effectiveness 
of  the  SSB  system. 

Weakness  4:  Implementation  of  the  SSB  system  will  require  a  cultural  shift 
from  an  independent  competitive  environment  to  a  collaborative 
interdependency  of  diverse  functional  groups. 

How  does  this  weakness  hinder  us  in  meeting  customer  needs? 

The  PMO  support  teams  that  have  already  been  established  to  take  of  the 
DMSMS  issues  and  are  quite  diverse  with  respect  to  the  teaming  methodology  and  have 
developed  their  current  culture.  Many  of  these  teams  use  working  group  techniques 
where  work  is  accomplished  off  line  in  functional  silos  then  brought  to  the  team  for 
approval  expecting  only  minor  changes.  Some  of  the  support  teams  accomplish  their 
work  as  an  IPT  and  leverage  the  cross  functional  aspects  of  the  group.  Sometimes  the 
PMO  support  comes  from  independent  functional  silos  that  have  little  use  for  the  teaming 
atmosphere.  The  variations  of  the  support  efforts  are  to  numerous  to  mention  although 


447 


there  seems  to  be  an  underlying  base  assumption  that  all  activities  and/or  functions  are 
vying  for  the  same  resource  pool  of  funding.  The  SSB  system,  to  be  successful,  must 
foster  an  atmosphere  of  a  “win-win”  scenario  and  stay  away  from  the  “zero  sum  game” 
so  prevalent  in  funding  resource  struggles.  The  SSB  system  will  need  inputs  from  and 
provide  outputs  to,  almost  every  function  on  the  support  team  and  therefore  the 
interdependency  relationships  need  to  be  established  and  matured.  The  lack  of  a  SSB 
system  friendly  environment  does  not  spell  out  failure  for  the  system  but  such  an 
environment  will  impede  implementation  progress  and  constrain  the  potential  benefits 
from  the  system. 

How  does  this  weakness  compare  to  our  competitors’  weaknesses?  Does  the  weakness 
make  us  different  from  (worse  than)  our  competitors  in  the  minds  of  our  customers? 

The  comparison  between,  the  way  support  teams  currently  do  business  and  the 
practices  used  in  the  SSB  system  will  be  evident  over  time  and  will  be  unique  to  each 
team.  The  implementation  of  the  SSB  system  will  require  a  certain  amount  of 
cooperation  and  adjustment  but  these  changes  are  usually  possible  within  most 
established  group’s  established  cultural  nonns.  From  the  perspective  of  the  customer,  the 
cultural  shift  is  more  of  a  challenge  that  should  be  eventually  overcome  instead  of  a 
“better  or  worse”  attribute. 

C.  OPPORTUNITIES 

Opportunity  1:  Meeting  the  PMO  objectives  in  providing  Life  Cycle  Cost 

(LCC)  reductions  of  50%  or  more  on  all  systems. 

How  is  this  opportunity  related  to  serving  the  needs  of  our  customer? 

The  LCC  is  one  of  the  primary  evaluation  criteria  placed  on  the  PMO  during  their 
annual  and  semiannual  reviews.  One  of  the  biggest  issues  the  PMO  faces  when 
quantifying  the  LCC  is  in  defining  the  parameters  that  need  to  be  measured  and  tracked. 
The  structure  of  the  SSB  system  encapsulates  these  metrics  into  a  reporting  system  that 
keeps  the  PMO  abreast  of  the  projected  and  actual  costs  incurred  by  the  program  with  the 
added  benefit  of  incorporating  other  non-SSB  point  solutions.  In  this  way  the  PMO  has 
an  oversight  view  regarding  the  true  cost  of  support  of  the  programs  systems. 
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What  actions  can  we  take  to  capitalize  on  this  opportunity  in  the  short  term? 

With  the  results  of  the  three  pilot  programs  available  to  us,  we  can  take  these 

results  and  draw  comparisons  with  other  target  programs,  which  have  shown  interest. 

The  three  example  programs  were  specifically  chosen  because  each  represents  a  specific 

part  of  the  developmental  cycle  such  as:  the  AN/ASQ-20X  Sonar  Mine  Detecting  Set 

program  is  just  finishing  the  Engineering  and  Manufacturing  Development  (E&MD) 

phase,  the  SSDS  MK  2  is  in  the  Production  phase  with  less  than  one  eighth  of  the 

projected  units  fielded,  the  SSDS  MK  1  is  considered  a  legacy  system  with  17  fielded 

system  that  need  to  be  supported,  as  is,  for  the  next  10  years.  The  most  complete  data  set 

we  have  compiled,  at  the  time  this  paper  was  written  is  for  the  SSDS  MK  1  systems 

although  the  data  for  the  other  system  is  still  being  compiled  and  so  far  seem  to  reflect 

the  same  type  of  LCC  reductions  as  experienced  with  the  MK  1  systems.  With  this 

implementation  experience  we  can  capitalize  on  the  fact  that  we  can  address  programs 

regardless  of  where  in  the  developmental  life  cycle  they  are  and  we  can  use  the  captured 

MK  1  data  set  to  show  expected  reductions  in  LCC. 

Opportunity  2:  The  SSB  system  defines  pro-active  risk  management  methods 
for  COTS  products  that  provide  the  Fleet  user  with  the  assurance  that  their 
system  will  be  supportable  over  time  and  available  when  needed. 

How  is  this  opportunity  related  to  sennng  the  needs  of  our  customer? 

Risk  management  like  LCC  is  an  evaluation  criteria  for  the  PMO  and  carries 
considerable  weight  with  their  resource  sponsors  in  obtaining  and  keeping  their  funding 
allocations.  The  SSB  system  is  the  only  post  design  pro-active  method,  known  to  the 
authors,  that  is  capable  of  yielding  a  quantifiable  COTS  obsolescence  risk  management 
method.  The  SSB  system  identifies  the  current  risk  state  and  a  projected  risk  state  in  a 
measurable  fashion  so  that  it  can  be  tracked  and  trended.  These  metrics  can  then  be  used 
by  the  PMO  as  objective  evidence  in  justification  of  the  funding  allocations. 

What  actions  can  we  take  to  capitalize  on  this  opportunity  in  the  short  term? 

Since  the  risk  management  methods  are  an  inherent  part  of  the  SSB  system  and 
reflected  in  the  reporting  processes  and  tools,  a  direct  analogy  can  be  made  with  any  new 
potential  program  and  the  three  programs  successfully  implemented.  The  reporting 
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products  used  on  the  three  programs  are  by  design  simple  graphical  representations  so 

they  can  be  readily  identifiable  by  the  PMO  representatives.  To  gain  the  most  leverage 

out  of  the  work  already  accomplished,  the  previously  prepared  risk  reports  will  be  briefed 

to  any  new  potential  candidate  programs  making  a  direct  comparison  between  the 

benefits  received  by  the  previous  program  and  the  candidate  program.  Additionally  there 

are  various  oversight  groups  who  have,  on  behalf  of  the  program’s  sponsor,  evaluated  the 

risk  management  aspects  provided  by  the  SSB  system  and  reported  their  findings  up  the 

ladder  to  the  resource  sponsor.  All  such  oversight  reports  have  been  positive  to  very 

positive  with  regards  to  the  processes  and  methods  used  when  implementing  the  SSB 

system  as  a  risk  reduction  and  management  method. 

Opportunity  3:  Growth  and  maturity  of  the  SSB  system  provides  greater 
opportunity  for  other  Navy  programs  to  leverage  this  unique  internal 
resource  expanding  its  value  proposition  to  the  Navy. 

How  is  this  opportunity  related  to  serving  the  needs  of  our  customer? 

The  first  programs  that  supported  the  implementation  of  the  SSB  system  had  no 
previous  work  to  leverage  from  and  therefore  needed  to  pay  for  each  relationship 
building  effort  and  every  configuration  assessment.  However  with  over  40  OEM 
relationships  established  and  analysis  of  over  130  configurations,  the  next  programs  to 
implement  will  more  than  likely  use  a  portion  of  the  previous  efforts.  The  expectation  is 
that  over  the  next  5-7  program  implementations,  the  amount  of  reuse  of  previous  work 
may  be  as  much  as  10-15%  of  the  total  effort.  The  implementation  efforts  which  follow 
are  expected  to  have  an  increased  percent  of  reuse  perhaps  eventually  yielding  as  much  as 
50%  reuse  in  later  implementation  efforts.  As  the  SSB  system  is  used,  implemented,  and 
matured  the  utility  the  programs  receive  from  it  will  increase  and  the  programs  sponsors 
will  look  favorably  upon  the  use  of  the  system  since  it  was  their  resources  that  are  being 
reused  instead  of  being  spent  on  efforts  which  “reinvent  the  wheel”. 

What  actions  can  we  take  to  capitalize  on  this  opportunity  in  the  short  term? 

The  actions  that  are  being  taken  to  exploit  this  reuse  characteristic  of  the  SSB 
system  is  to  make  available  the  list  of  OEM  participants  and  the  specific  configurations 
that  the  SSB  system  was  implemented  on.  On  a  personal  sell  level  we  use  the  current 
listing  as  an  example  of  the  potential  out  come,  then  identify  if  any  of  the  configurations 
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appearing  on  the  list  or  OEM  names  on  the  list  are  a  match  to  the  new  potential  candidate 
system.  If  an  exact  configuration  match  takes  place,  we  offer  to  share  the  obsolescence 
risk  analysis  with  the  new  program.  If  further  interest  is  apparent  and  the  program  is 
willing  to  engage  further  analysis,  we  could  work  with  program  representatives  to 
prepare  a  risk  mitigation  report  specific  to  the  program’s  needs  (i.e.  part  number  obsolete, 
how  many  parts  per  assembly,  how  many  assemblies  per  new  system,  how  many  new 
systems,  how  long  is  the  expected  support  window,  etc.)  A  quick  demonstration  of  the 
SSB  systems  capabilities  will  illustrate  to  the  program  the  real  utility  of  the  information 
and  the  subsequent  knowledge  gained  through  its  use.  In  order  to  reach  a  large  or  mass 
audience  with  this  information,  we  have  near  term  plans  to  post  the  information  on  a  web 
site  used  by  our  target  audience.  The  GIDEP  (Government  Industry  Data  Exchange 
Program)  web  site(  www.gidep.gov  )  has  over  1,500  membership  organizations  boasting 
a  user  pool  of  over  4,500  individual  users.  During  the  MIL-Spec  era  before  Acquisition 
Reform,  membership  in  this  system  was  one  of  the  acquisition  requirements  for  all  Navy 
programs  and  their  prime  contractors,  therefore  most  of  our  potential  new  program 
candidates  will  have  access  to  this  system.  The  GIDEP  organization  has  agreed  to  host  a 
list  of  OEM  participants  and  the  specific  configurations  contained  in  the  current  SSB 
system  active  participation  lists.  All  presentation  materials  and  future  announcements 
will  subsequently  be  updated  to  reflect  this  reference  whereby  it  can  be  tapped  as  a  ready 
reference. 

Opportunity  4:  The  SSB  system  employees  several  simulation  and  modeling 

tools  to  optimize  the  business  planning  and  future  support  requirements  for 

fielded  program  systems. 

How  is  this  opportunity  related  to  serving  the  needs  of  our  customer  ? 

As  part  of  the  implementation  effort  regarding  the  SSB  system,  detailed  resource 
and  procurement  models  were  prepared  for  the  SSDS  MK  1  system  from  which  various 
scenarios  can  be  simulated  iteratively  and  recursively  showing  the  possible  outcomes.  It 
can  easily  be  demonstrated  that  the  structure  of  these  tools  allows  modification  and 
customization  to  be  applicable  to  most  any  program.  Furthermore  the  results  of  running 
the  various  models  using  the  SSDS  MK  1  data  provides  a  stunning  real  life  example  of 
the  positive  results  attainable  through  SSB  system  implementation.  To  the  authors 
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knowledge,  no  other  system  or  method  has  identified  a  method  to  work  within  the  PPBS 
funding  system  to  support  an  overarching  DMSMS  support  system.  These  models  are 
tailored  to  reflect  the  requirements  of  the  PPBS  system  such  that  the  outputs  from  the 
models  could  be  directly  transferred  to  the  Funding  Allocation  Request  (FAR)  an  input  to 
the  PPBS  system.  The  procurement  models  identify,  within  the  constraints  levied  by  the 
program,  the  expected  level  of  support  with  regards  to  the  hardware  for  each  year  of 
support.  These  levels  are  predicted  based  on  the  actual  failure  rate  exhibited  in  the  fleet. 
The  resource  modeling  is  accomplished  using  the  NSWC  Crane  cost  model,  which  takes 
into  account  all  the  various  aspects  of  implementing  an  Engineering  Change  Proposal 
(ECP).  This  model  covers  over  128  functions/activities  and  is  tailored  to  meet  the  needs 
of  the  application  under  consideration.  Between  these  two  models  and  a  few  other  tools 
used  in  the  SSB  system,  the  program  can  get  the  “Big  Picture”  view  of  the  supportability 
requirements  for  their  program. 

What  actions  can  we  take  to  capitalize  on  this  opportunity  in  the  short  term? 

Every  program  has  a  requirement  to  substantiate  and  justify  their  business 
planning  (funding  and  allocation),  support  strategy,  and  risk  management  efforts.  The 
knowledge  of  these  requirements  and  the  inherent  capabilities  of  the  SSB  system  which 
are  designed  into  the  system  to  meet  the  program  needs  and  this  information  must  be 
communicated  when  presenting  the  system  to  a  candidate  program.  Again,  the  use  of  the 
SSDS  MK1  data  set  in  the  models  then  running  simulations  structured  around  the 
constraints  of  the  candidate  program  can  be  an  illustrative  and  convincing  tool.  These 
simulations  can  be  run  quickly  providing  immediate  results  to  show  the  new  candidate 
program  that  the  constraints  presented  by  their  program  can  fit  within  the  modeling 
structure.  Showing  the  applicability  of  the  tool  and  methods  within  the  confines  of  the 
candidate  program  will  provide  them  some  assurance  of  potential  success.  The 
confidence  gained  through  these  demonstrations  may  be  enough  to  bridge  the  gap  and 
provide  a  comfort  level  great  enough  to  make  the  up-front  commitment  and  provide 
adequate  resources  to  implement  the  SSB  system  on  their  program. 
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Opportunity  5:  The  Naval  Audit  Service  (NAS)  has  recently  released  reports 
indicating  that  the  implementation  of  the  Contractor  Logistic  Support  (CLS) 
contracting  methodologies  used  by  NAVSEA  and  SPAWAR  lacks  adequate 
visibility  and  metrics  that  would  assure  proper  oversight. 

How  is  this  opportunity  related  to  serving  the  needs  of  our  customer? 

The  NAS  report  numbers  N2002-0049  [20)  NAS  NAVSEA]  and  N2002-0069 
[21)  NAS  SPAWAR]  both  identify  a  lack  of  a  performance  plan,  strategy,  or 
management  control  to  implement  the  CLS  acquisition  refonn  initiative  by  NAVSEA  and 
SPAWAR  respectively.  The  lack  of  controls  and  measurements  to  achieve  the  desired 
results  of  reduced  cost  and  improve  system  availability  was  identified  as  an  inadequacy 
in  Program  Management.  CLS  can  and  many  times  does  take  into  account  the  DMSMS 
support  functions  usually  in  the  fonn  of  Performance  Based  Logistics  (PBL)  contracting 
methods.  As  discussed  earlier  in  this  plan,  PBL  contracting  methods  do  not  provide  the 
most  advantageous  environment  for  the  Organic  field  activities  participation  including 
the  use  of  the  SSB  system.  Both  SYSCOMs  (NAVSEA  &  SPAWAR)  need  to  develop 
reporting  and  management  structures  to  overcome  the  identified  shortcomings. 

What  actions  can  we  take  to  capitalize  on  this  opportunity  in  the  short  term? 

The  BCA  prepared  in  support  of  the  SSB  system  in  conjunction  with  the  reporting 
mechanisms  inherent  to  the  SSB  system  will  meet  these  shortcomings  reported  by  NAS. 
The  reporting  and  management  structures  needed  by  the  SYSCOMs,  have  already  been 
set  up  and  are  functioning  for  COTS  supportability,  available  only  if  the  programs  choose 
to  implement  the  SSB  system.  The  SYSCOMs  management  and  the  Program  Managers 
need  to  be  informed  of  the  availability  of  the  SSB  system  in  order  to  leverage  the 
currently  available  assets.  This  additional  attribute  of  the  SSB  system  should  be 
announced  at  the  same  time  we  communicate  the  potential  negative  impacts  when  CLS  or 
PBL  are  implemented  through  NAVICP  using  their  exclusionary  implementation 
practices. 
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Opportunity  6:  In  early  September  2002  Secretary  of  Defense  office 
rescinded  the  existing  DoD  5000  series  documents  with  a  memo  that  stated, 
the  identified  hard  requirements  -  the  “must  do”  -  Systems  Engineering 
methods  will  be  replaced  by  a  guidance  document  to  provide  more  leeway  to 
the  Program  Managers. 

How  is  this  opportunity  related  to  serving  the  needs  of  our  customer? 

The  removal  of  requirements  documents  relaxes  the  discipline  required  by  the 
implemented  processes  and  inevitably  produces  larger  risks  to  the  Program  Manager 
(PM)  and  the  acquisition  process.  To  be  successful  in  a  requirements  poor  environment 
the  PM  must  institute  risk  management  methods  and  practices  to  maintain  control  or  at 
least  visibility  into  the  program  activities.  With  this  new  change  of  direction  from  DoD 
the  need  for  the  risk  management  disciplines  increases  dramatically  and  must  be 
instituted  on  a  continuous  ongoing  basis.  The  SSB  System  is  a  risk  management  method 
for  COTS  products. 

What  actions  can  we  take  to  capitalize  on  this  opportunity  in  the  short  term? 

The  communications  with  the  customer  base  should  identify  the  obsolescence  risk 
management  attributes  of  the  SSB  system  and  how  these  attributes  provide  the  PM  with 
the  visibility  into  the  program  activities.  One  of  the  keys  to  illustrating  the  utility  of  the 
system  will  be  in  displaying  reporting  products  from  previously  assessed  COTS  products 
on  other  programs  especially  if  they  are  also  used  on  the  PMs’  equipment.  The 
continuous  and  all  encompassing  insight  provided  through  the  reporting  mechanisms  as 
part  of  the  SSB  system  are  packaged  and  tailored  to  meet  the  needs  of  the  program. 

D.  THREATS 

Threat  1:  Current  contracting  implementation  policy  regarding  Performance 
Based  Contracting  (PBC)  may  curtail  or  eliminate  the  possibility  of  using  the 
SSB  system. 

How  is  this  threat  related  to  serving  the  needs  of  our  customer? 

As  identified  in  the  preceding  material,  the  implementation  policies  of  NAVICP 
can  preemptively  exclude  the  participation  of  all  Organic  activities  and  therefore  exclude 
the  SSB  system.  The  PMO  may  unknowingly  task  NAVICP  to  subcontract  out  the 
DMSMS  support  functions  believing  that  the  “best  value”  for  their  program  will  result 
from  a  competitive  environment.  As  discussed  in  detail,  NAVICP  does  not  provide  a 
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competitive  environment  nor  do  their  processes  assure  “best  value”,  therefore  without 
prior  knowledge  of  the  contracting  environment  or  intimate  knowledge  of  the  capabilities 
of  the  SSB  system  the  programs  may  never  know  of  these  shortcomings. 

What  actions  can  we  take  to  prevent  this  threat  from  limiting  our  capabilities  in  the  short 
term  and  in  the  long  term  ? 

NAVICP’s  exclusionary  policies  are  either:  1)  an  unintended  consequence  of  their 
goal  to  streamline  their  processes,  or  2)  intended  to  streamline  and  optimize  their  internal 
processes  while  in  the  bigger  picture  does/may  not  provide  the  Navy  with  the  “best 
value”.  Regardless  of  the  reason  for  or  logic  behind  these  policies,  the  impact  of  them 
needs  to  addressed.  A  three  pronged  approach  is  recommended  in  dealing  with  the 
current  situation:  1)  address  NAVICP  directly  through  a  set  of  meeting  with  the  decision 
makers  to  illustrate  the  impacts  of  the  policies  and  show  bottom  line  figures  from 
implemented  examples  of  the  SSB  system  and  show  what  the  Navy  is  missing  out  on 
because  of  their  policies,  hopefully  resulting  in  a  change  in  policy  direction,  2)  since  it 
has  been  shown  that  their  policies  are  in  conflict  with  the  guidance  documents  and 
executive  mandates,  that  a  request  for  clarification  be  sent  to  Secretary  of  the  Navy, 
Advocate  for  Competitive  Environment  and  have  NAVICP  implementation  policies 
reviewed  for  adequacy  and  possible  revision,  and  3)  develop  a  mass  broadcast  to  all  PMO 
and  provide  them  with  intimate  knowledge  of  the  SSB  system  and  specifically  highlight 
the  shortcomings  of  the  NAVICP  implementation  policies.  All  three  of  these  approaches 
are  being  undertaken  at  this  time.  With  the  completion  of  the  Business  Case  Analysis 
(BCA)  as  a  result  of  the  SSB  system  implementation  process  for  SSDS  MK  1,  we  will 
have  accurate  real  data  to  prove  the  viability  of  the  SSB  alternative  and  with  that  data  we 
can  approach  NAVICP  with  a  supportable  and  justifiable  case  in  point.  A  set  of 
clarification  questions  have  been  prepared  and  is  being  sent  to  the  point  of  contact  in  the 
SECNAV  office  to  review  our  interpretations  of  the  cause  and  affect  impacts  due  to  the 
NAVICP  implementation  policies.  Articles  are  being  prepared  for  three  separate 
publications  well  read  by  our  target  audience: 

1)  The  COTS  Journal, 

2)  Defense  Acquisition  University  (DAU)  -  Acquisition  Review  Quarterly,  and 

3)  Defense  Acquisition  University  -  Program  Manager,  PM  Magazine. 
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Additionally  the  following  conferences  and  workshops  have  been  or  will  be 
presenting  the  SSB  system  during  the  event  and  contained  as  part  of  the  proceedings: 

1)  2002  GIDEP  Workshop  and  Infonnation  Sharing  Conference,  May  24-16, 

2002,  San  Diego,  CA. 

2)  2002  International  Military  &  Aerospace/Avionics  COTS  Conference, 
Exhibition  &  Seminar,  San  Diego,  CA. 

3)  Naval-Industry  R&D  Partnership  Conference,  Sponsored  by  Office  of  Naval 
Research,  August  13-14,  2002,  Washington  D.C. 

4)  Government  Industry  Association  (GIA)  Conference,  September  10-11,  Kent, 
WA. 

5)  National  Defense  Industrial  Association  (NDIA),  5th  Annual  Systems 
Engineering  Conference,  October  21-24,  Tampa,  FL. 

6)  NAVSEA  COTS  Steering  Board  Workshop  2002,  October  30-31,  Laurel,  MD, 

7)  The  7th  International  Commercialization  of  Military  and  Space  Electronics 
Conference  &  Exhibition  (CMSE),  February  10-13,  2003,  Los  Angeles,  CA. 

Of  these  seven  conferences/workshops,  all  have  confirmed  acceptance  of 

submitted  abstract  and  materials  with  the  exception  of  the  last  entry  #7.  With  regard  to 

the  long  term  mitigation  of  this  threat,  our  plans  are  to:  1)  Institutionalize  the  SSB  system 

as  a  standard  alternative  by  updating  the  DAU  publication  -  Program  Managers 

Handbook  -  to  reflect  the  SSB  system  as  the  preferred  practice,  2)  keep  vigilant  with 

regard  to  the  DMSMS  community  by  providing  presentations  at  future 

conferences/workshops,  3)  provide  face  to  face  presentations  to  as  many  programs  as 

possible,  thus  far  over  a  dozen  such  presentations  have  been  given,  4)  present  to  the 

Program  Executive  Offices  (PEOs)  and  resource  sponsors  showing  the  bottom  line 

benefits  to  get  a  top  down  endorsement/sponsorship. 

Threat  2:  Subcontracting  government  DMSMS  support  personnel  to 
contractors  creates  a  “conflict  of  interest”  situation  for  the  government 
employee  while  yielding  sub  optimal  results  for  the  Navy. 

How  is  this  threat  related  to  serving  the  needs  of  our  customer? 

The  primary  purpose  in  implementing  the  SSB  system  is  to  provide  the  “best 
value”  to  the  Navy  through  defining  a  process  yielding  manageable  risk  at  the  lowest 
LCC.  If  a  “conflict  of  interest”  situation  exists  either  within  the  contractor  -  the  bottom 
line  versus  “best  value”  for  the  Navy  -  or  with  the  government  employee  trying  to 
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balance  the  requirements  of  -  their  employer  directives  versus  “best  value”  for  the  Navy 
-  the  lack  of  independence  of  DMSMS  support  function  will  most  likely  produce  sub 
optimal  results  for  the  Navy.  Since  the  NAVICP  implementation  policies  have  no 
counter  acting  force  or  “change  agent”  activists,  contracting  out  this  vital  function 
appears  inevitable.  Over  time  the  internal  Organic  activities  will  become  either  the 
willing  participants  of  the  contractor’s  directives  or  a  non-participant  whereby  the 
internal  Navy  resources  for  DMSMS  support  will  eventually  disappear.  In  the  end  the 
PMO  (customer)  will  receive  DMSMS  support  that  will  reflect  the  contractor’s  -  “best 
bottom  line”  -  versus  the  Navy’s  -  “best  value”. 

What  actions  can  we  take  to  prevent  this  threat  from  limiting  our  capabilities  in  the  short 
term  and  in  the  long  term  ? 

The  same  action  plan  identified  for  Threat  1  is  applicable  with  regard  to  the 
“conflict  of  interest”  issues  although  a  few  actions  will  require  modification.  With  a 
“conflict  of  interest”  problem  the  issues  take  on  more  of  a  political  overtone  versus  the 
straight  business  implications  in  arriving  at  the  “best  value”  for  the  Navy,  as  identified  in 
Threat  1 .  Therefore  it  is  important  to  work  this  issue  in  a  low-key  fashion  up  the  chain  of 
command  instead  of  broadcasting  it  at  every  conference  and  workshop.  The  preventative 
actions  to  mitigate  this  threat  are  to  confront  NAVICP  directly  and  request  interpretation 
and  action  from  SECNAV. 
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THE  SWOT  MATRIX  FOR  THE  SSB  SYSTEM 

STRENGTHS 

•  An  expandable,  transportable 
and  Life  Cycle  Cost  (LCC) 
reducing  processes,  methods, 
and  tools 

•  New  supportability  options  to 
the  PMOs 

•  Proactive  COTS  obsolescence 
risk  management  process 

•  Enables  Business  planning  and 
Management  processes  for 
fielded  systems 

OPPORTUNITIES 

•  Life  Cycle  Cost  (LCC) 
reductions  of  as  much  as  50% 
on  all  systems  depending  on 
program  constraints 

•  Provide  the  Fleet  user  with  the 
assurance  that  their  system  will 
be  supportable  over  time  and 
available  when  needed 

•  The  greater  the  use  of  the 
system  the  greater  the  leverage 
to  be  gained,  thereby 
expanding  its  value  proposition 
to  the  Navy 

•  Simulation  and  modeling  tools, 
optimize  the  business  planning 
and  identify  future  support 
requirements 

•  The  SYSCOMs  require  a 
performance  plan,  strategy, 
and  management  control  for 
CLS/PBL  contracting  efforts 

•  DoD  has  a  greater  need  for  risk 
management  methods  and 
practices  due  to  the  changes  in 
the  DoD  5000  series 
documents 

WEAKNESSES 

•  New  system  with  a  very  short 
track  record 

•  Up-front  PMO  support  and 
long-term  commitment  on 
behalf  of  the  PMO  and  the 
support  team 

•  The  SSB  system  is  not  part  of 
the  mainstream  contracting 
process  implemented  by 
NAVICP 

•  Requires  a  cultural  shift  from 
an  independent  competitive 
environment  to  a  collaborative 
interdependency 

THREATS 

•  Implementation  policy 
regarding  Perfonnance  Based 
Contracting  (PBC)  may  curtail 
or  eliminate  the  possibility  of 
using  the  SSB  system 

•  Subcontracting  government 
DMSMS  support  personnel  to 
contractors  creates  a  “conflict 
of  interest”  situation  for  the 
government  employee  while 
yielding  sub  optimal  results  for 
the  Navy 

Appendix  D  Table  2:  SWOT  Matrix 
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E.  SWOT  MATCHING,  CONVERTING,  MINIMIZING,  AND  AVOIDING 
STRATEGIES 

How  can  we  match  our  strengths  to  our  opportunities  to  create  capabilities  in  sending  the 
needs  of  our  customers? 

Strengths: 

1)  An  expandable,  transportable,  Life  Cycle  Cost  (LCC)  reducing  processes, 
methods,  and  tools 

2)  New  supportability  options  to  the  PMOs 

3)  Proactive  COTS  obsolescence  risk  management  process 

4)  Enables  Business  planning  and  Management  processes  for  fielded  systems 

Opportunity  1:  Meeting  the  PMO  objectives  in  providing  Life  Cycle  Cost 
(LCC)  reductions  of  as  much  as  50%  on  all  systems  depending  on  program 
constraints. 

The  opportunity  to  reduce  the  LCC  by  50%  will  be  a  result  of  combining  three 

strengths  (1,  2,  4)  together  to  maintain  an  environment  where  the  PMO  has  cost  effective 

options,  which  can  be  planned  for  and  then  implemented  according  the  plan. 

Implementing  the  processes,  methods,  and  tools  of  the  SSB  system  as  part  of  the  Systems 

Architecture  will  leverage  other  functional  areas  based  on  sound  Business  Planning  and 

Management  processes  that  will  provide  the  PMO  with  options.  The  variety  of  options 

available  to  the  PMO  due  to  the  SSB  system’s  structure  allow  programmatic  decisions  to 

take  into  account  the  program’s  core  requirements  by  elevating  many  of  the  once  hard 

and  fast  constraints  inherent  in  COTS  products.  Using  this  flexibility  the  PMO  can 

choose  to  focus  on  reducing  the  overall  program  LCC. 

Opportunity  2:  The  SSB  system  defines  pro-active  risk  management  methods 
for  COTS  products  that  provide  the  Fleet  user  with  the  assurance  that  their 
system  will  be  supportable  over  time  and  available  when  needed. 

The  long-term  supportability  of  fielded  systems  is  the  primary  purpose  of  the  SSB 
system  because  it  directly  impacts  the  availability  and  utility  of  the  fielded  systems  used 
by  the  Fleet.  The  processes,  methods,  and  tools  identify  the  specific  obsolescence  risks 
involved  with  each  COTS  product,  the  Business  Planning  and  Management  processes  are 
then  used  to  manage  these  risks  through  the  use  of  a  cross  functional  team.  The  emergent 
property  provided  by  the  SSB  system  associated  with  this  identification  and  management 
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practice  yields  the  assurance  that  the  fielded  COTS  products  will  have  long-term  support 
and  predictable  performance  to  meet  the  Fleet  user  requirements.  The  strengths  (1,3,4) 
map  directly  to  the  pro-active  risk  management  whereby  the  Fleet  user  requirements  are 
met. 

Opportunity  3:  Growth  and  maturity  of  the  SSB  system  provides  greater 
opportunity  for  other  Navy  programs  to  leverage  this  unique  internal 
resource  expanding  its  value  proposition  to  the  Navy. 

The  expandable  and  transportable  characteristics  identified  in  strength  #1,  directly 

influences  the  leveraging  opportunity,  which  expands  the  value  proposition  to  the  Navy. 

The  SSB  system  establishes  a  reusable  foundation  of  relationships  with  the  OEMs  and 

detailed  information  with  respect  to  specific  configurations  whereby  subsequent  program 

implementations  that  use  the  same  COTS  products  will  not  need  to  redo  this  work  but 

instead  just  reuse  the  current  established  information.  The  logical  follow-on  to  this 

capability  is  that  as  the  Navy  implementation  of  the  SSB  system  increases  the  possibility 

of  reuse  also  increases  and  therefore  greater  leverage  can  be  captured.  The  attributes  of 

planning  and  managing  identified  in  strength  4  provide  the  PMO  with  the  methods  and 

practices  to  take  advantage  of  the  reuse  capability  and,  as  a  product  of  the  Systems 

Engineering  approach,  allow  the  expansion  of  the  value  added  proposition  to  the  Navy. 

Opportunity  4:  The  SSB  system  employs  several  simulation  and  modeling 
tools  to  optimize  the  business  planning  and  future  support  requirements  for 
fielded  program  systems. 

All  four  strengths  in  some  way  support  the  simulation  and  modeling  tool  and  the 

ability  to  do  business  planning  specifically  required  for  forecasting  of  funding 

requirements  and  future  fielded  product  needs.  The  predictive  attributes  of  the  SSB 

system  are  a  direct  result  of  the  inherent  characteristics  of  the  System  Architecture  and 

the  Systems  Engineering  approach  employed  in  the  SSB  system’s  design. 

Opportunity  5:  The  Naval  Audit  Service  (NAS)  has  recently  released  reports 
indicating  that  the  implementation  of  the  Contractor  Logistic  Support  (CLS) 
contracting  methodologies  used  by  NAVSEA  and  SPAWAR  lacks  adequate 
visibility  and  metrics  that  would  assure  proper  oversight 

The  first  and  fourth  strengths  map  directly  to  this  opportunity,  in  that,  the  SSB 
system  contains  processes,  methods,  and  tools,  which  provide  the  infrastructure  necessary 
to  support  the  business  and  management  needs  that  were  found  to  be  lacking  identified  in 
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the  NAS  reports.  This  infrastructure  is  an  inherent  part  of  the  SSB  system  and  can  be 
directly  transferable  to  a  program  to  meet  the  shortcomings  they  (the  programs)  currently 
exhibit. 

Opportunity  6:  In  early  September  2002  Secretary  of  Defense  office 
rescinded  the  existing  DoD  5000  series  documents  [22)  DJSM]  with  a  memo 
that  stated,  the  identified  hard  requirements  -  the  “must  do”  -  Systems 
Engineering  methods  will  be  replaced  by  a  guidance  document  to  provide 
more  leeway  to  the  Program  Managers. 

One  of  the  predominate  strengths  provided  through  the  SSB  system  is  the  ability 
to  manage  the  obsolescence  risk  inherent  in  COTS  products.  Additional  support 
processes,  methods  and  tool  available  through  the  use  of  the  SSB  system  allows  the  PM 
insight  into  the  programmatic  activities  and  associated  costs  to  the  program  in  managing 
the  long-term  supportability  issues.  With  the  relaxation  of  the  constraints  on  the 
Requirements  Generation  System  the  key  to  success  for  the  PM  will  be  in  managing  the 
risks  involved  with  this  approach,  the  SSB  system  has  been  developed  to  help  with  this 
task. 

How  can  we  convert  our  weaknesses  into  strengths? 

Weaknesses: 

1)  The  SSB  system  is  a  new  system  with  a  very  small  track  record. 

2)  The  SSB  system  necessitates  the  up-front  PMO  support  and  a  long-term 
commitment  on  behalf  of  the  PMO  and  the  support  team. 

3)  The  SSB  system  is  not  part  of  the  mainstream  contracting  process  implemented 
by  NAVICP. 

4)  Implementation  of  the  SSB  system  will  require  a  cultural  shift  from  an 
independent  competitive  environment  to  a  collaborative  interdependency  of 
diverse  functional  groups. 

Weaknesses  1&4: 

The  issues  identified  in  weaknesses  1  &  4  can  be  directly  linked  and  converted 
into  opportunities  using  the  same  approach  essentially  “killing  two  birds  with  one  stone”. 
The  competitive  environment  illustrated  earlier  in  this  plan  identifies  many  of  the 
characteristics  shown  by  existing  DMSMS  support  groups.  Characteristics  such  as  “rice 
bowl”  mentality,  the  “not  invented  here”  attitude,  and  “functional  stove  pipes”  are  typical 
of  existing  DMSMS  support  groups.  These  attitudes  are  exacerbated  by  the  newness  of 
the  SSB  system’s  approach  and  can  only  be  converted  into  strengths  by  proving  out  the 
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system.  The  proving  out  process  will  require  objective  evidence  showing  that  once  the 
system  has  been  implemented  as  a  collaborative  process  the  resulting  impact  to  the 
program  lowers  LCC,  reduces  COTS  obsolescence  risk  and  provides  the  PMO  with 
additional  options  not  available  prior  to  the  SSB  system  implementation.  Therefore  the 
converting  mechanism  to  go  from  a  weakness  to  a  strength  will  be  evident  through  the 
data  collected  quantifying  the  success  or  failure  of  implementing  the  SSB  system. 
Keeping  a  well  defined  set  of  metrics  regarding  LCC  reductions  and  impacts  to  fielded 
systems  supportability  and  using  these  values  to  illustrate  the  utility  of  the  system  will  be 
critical  in  having  the  SSB  system  embraced  by  existing  DMSMS  supports  groups. 

Weakness  2: 

Although  the  set  of  metrics  listed  above  will  be  pivotal  in  proving  the  viability  of 
the  SSB  system  some  additional  information  may  be  needed  to  convince  the  PMO  and 
support  teams  to  make  long-term  commitments  and  provide  the  upfront  resources.  Two 
approaches  can  be  undertaken  to  address  these  concerns.  Assuming  the  viability  of  the 
SSB  system  has  been  demonstrated  through  the  metrics,  a  case  needs  to  be  made  that  the 
metrics  taken  over  time  is  where  the  big  payoff  is  for  the  implementation  of  the  SSB 
system.  This  case  is  well  illustrated  in  the  Business  Case  Analysis  (BCA),  which  can  be 
provided  as  objective  evidence.  However,  just  as  impressive  would  be  a  testimony  from 
a  PMO  where  the  impact  to  the  PMO’s  systems  could  be  relayed  to  other  PMOs 
considering  the  SSB  system  alternative.  This  testimony  could  be  as  simple  as  a  phone 
call  or  perhaps  a  more  formal  written  statement  of  accomplishments  due  to  SSB  system 
implementation.  The  testimony  coupled  with  justification  data  available  in  the  BCA 
presents  a  strong  case  for  making  the  long-term  commitment.  The  second  approach  to 
gain  the  up-front  support  can  be  gleaned  from  the  BCA  and  other  data  by  examining  the 
particular  programmatic  system  in  question  and  developing  predictive  indicators  that 
show  potential  impacts  to  the  program.  One  such  indicator  would  be  calculation  of  the 
Return  On  Investment  (ROI)  using  the  criteria  from  the  program  in  question.  This  value 
will  bring  home  to  the  program  the  viability  of  the  SSB  system  when  used  to  meet  the 
program  objectives. 
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Weakness  3: 


As  identified  in  several  sections  of  this  plan,  the  implementation  policies  of 
NAVICP  can  present  limitations  to  the  SSB  implementation  efforts  although  some  “work 
around”  and  direct  confrontational  alternatives  have  been  discussed.  These  alternatives 
necessitate  additional  work  in  order  to  get  the  SSB  system  to  receive  adequate 
consideration.  Notwithstanding  the  negative  impacts  this  has  on  the  SSB  system 
implementation  efforts  the  situation  does  have  some  redeeming  qualities.  The  current 
contracting  situation  requires  the  SSB  system  implementation  efforts  to  prove  out  its 
utility  based  on  its  own  merits  and  advertise  or  broadcast  to  a  wide  range  of  potential 
candidate  PMOs.  If  the  SSB  system  is  accepted  based  on  its  proven  utility  to  PMOs  in 
spite  of  the  lack  of  support  from  the  contracting  processes,  then  like  many  successful 
“grass  roots”  initiatives  the  success  will  help  change  the  contracting  process.  Use  of  the 
SSB  system  alternative  may  be  the  key  in  incorporating  the  Organic  activities 
involvement  on  future  DMSMS  support  teams  regardless  of  the  contracting  methodology. 
Should  this  become  the  case,  the  SSB  system  will  be  a  positive  and  necessary  alternative 
to  be  encapsulated  in  the  DMSMS  support  team  planning  when  accomplished  by  any 
Organic  activity. 

How  can  we  convert  our  threats  into  opportunities? 

How  can  we  minimize  or  avoid  those  weaknesses  and  threats  that  cannot  be  successfully 
converted? 

Both  identified  threats  are  a  result  of  the  NAVICP’s  implementation  policies  with 
regards  to  Perfonnance  Based  Contracting  (PBC).  Three  strategies  have  been  identified 
to  deal  with  these  threats:  directly  confronting  NAVICP,  request  SECNAV  intervention, 
and  increase  the  awareness  of  the  SSB  system  in  the  DMSMS  support  community.  By 
confronting  NAVICP  directly  there  is  a  potential  that  they  could  alter  their  policies  to 
mitigate  the  issues  regarding  Organic  activities  participation,  this  change  could  also  go 
even  further  and  allow  the  SSB  system  to  compete  in  an  environment  having  a  level 
playing  field,  a  situation  that  would  favor  incorporation  of  the  SSB  system  as  the 
preferred  alternative.  SECNAV  intervention  is  another  method  to  instigate  the  same  kind 
of  potential  changes  as  identified  with  direct  confrontation  with  NAVICP.  Either  of  these 
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methods  could  result  in  converting  the  threats  to  opportunities.  The  third  strategy  of 

raising  the  awareness  of  the  SSB  system  is  meant  to  avoid,  as  much  as  possible,  the 

negative  impact  of  the  contracting  policies  if  they  cannot  be  converted. 

Do  we  possess  any  major  liabilities  (unconverted  weaknesses  that  match 
unconverted  threats)? 

Are  these  liabilities  and  limitations  obvious  to  our  customers?  Are  there  ways  that  these 
liabilities  and  limitations  can  be  minimized  or  avoided? 

There  is  one  area  in  which  we  carry  a  liability  and  that  is  in  the  area  of  customer 
(PMO  and  support  teams)  perception  of  the  intent  of  the  SSB  system.  Many  potential 
customers  at  first  glance  will  look  at  the  SSB  system’s  as  having  the  intentions  of  sending 
old,  antiquated  technology  out  to  the  Fleet  and  forcing  this  sub-par  equipment  on  them 
for  time  indefinite.  Although  this  first  perception  is  not  the  intention  nor  does  it  describe 
the  purpose  of  the  SSB  system,  it  is  a  liability,  which  must  be  overcome.  To  address  this 
issue  we  will  be  developing  through  this  plan,  methods  and  tools  to  project  an  “Image” 
that  is  more  closely  aligned  with  the  purpose  and  objectives  intended  through  the  use  of 
the  SSB  system. 
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V.  MARKETING  GOALS  AND  OBJECTIVES 


The  marketing  objectives  involve  establishing  the  SSB  system  as  a  unique 
standard  practice  while  projecting  the  image  as  an  enabler  of  currently  used  support 
systems,  that  are  employed  during  the  decision-making  processes  regarding 
supportability  of  COTS  products.  Our  current  goal  of  20%  capture  of  the  Navy  programs 
translates  to  72  programs  or  an  equivalent  80  man-years  per  year,  and  it  is  estimated  that 
this  amount  of  captured  programs  will  establish  the  SSB  system  as  one  of  the  standard 
solution  alternatives. 

A.  MARKETING  GOAL  A 

•  Implement  the  SSB  system  on  20%  of  the  available  Navy  programs  over  the 
next  3  years. 

Objective  A1 

•  Project  the  amount  of  Organic  activity  workload  generated  by  capture  of  20% 
of  the  available  Navy  programs. 

Specific  and  Measurable  outcome: 

The  total  available  estimated  market  size  is  the  sum  of  all  programs  within  the 
Navy  and  that  value  is  365  programs.  The  size  of  each  program  is  unique  —  some  are 
very  small  (i.e.  small  unique  pieces  of  equipment)  while  others  are  extremely  large  like 
AEGIS  and  the  Virginia  Class  submarines.  The  SSB  system  is  designed,  to  be  tailored  to 
meet  the  needs  of  the  programs,  this  includes  the  size  and  other  unique  factors  specific  to 
a  program.  The  larger  the  program  size,  the  more  expansive  the  SSB  effort  becomes  for 
that  given  program.  The  number  of  programs  directly  relates  to  the  number  of  potential 
customers  and  each  customer  will  have  a  unique  SSB  effort  tailored  to  its  needs.  The 
amount  of  COTS  products  on  a  program  will  also  define  the  SSB  efforts  since  the  SSB 
system  is  designed  to  provide  long-term  supportability  for  the  COTS  products. 

In  an  effort  to  estimate  the  amount  of  COTS  on  the  total  distribution  of  Navy 
acquisition  programs  we  queried  the  COTS  database  at  NSWC  Crane.  This  database 
contains  several  Navy  acquisition  programs,  of  them  13  were  evaluated  and  assigned  an 
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estimate  of  the  percent  of  COTS  per  program  using  engineering  judgment,  as  identified  in 
Table  1  [23)  Braun]. 


Program 

Equipment  Type 

%  COTS 

AN/SPS-48E 

Radar 

30% 

AN/SPS-73(V)12 

Radar 

75% 

CEC 

Cooperative  Engagement 
Capability 

67% 

SLQ-32 

Electronic  Countermeasures 

15% 

LPD-17  SWAN 

Shipboard  Wide  Area  Network 

95% 

AN/SSN-6 

Navigation  Sensor  System 

Interface 

75% 

MK162 

Ship  Gridlock  System 

90% 

MK98  Mod  4 

Trident  Fire  Control 

70% 

AN/BQO- 10ARCI 

Sonar  System 

85% 

AN/MSQ-124 

Air  Defense  Communications 
Platform 

75% 

SSDS  MK1 

Ships  Self  Defense  System 

98% 

SSDS  MK2 

Ships  Self  Defense  System 

98% 

AN/AQS-20/X 

Sonar  Mine  Detecting  Set 

20% 

Appendix  D  Table  3:  Percentage  COTS  of  some  Navy  systems 

Using  the  data  presented  in  Table  3  a  distribution  for  the  percentage  of  programs 
using  various  levels  of  COTS  within  the  systems  can  be  calculated.  The  assumption 
made  when  developing  this  distribution  is  that  the  Navy  system  has  undergone  COTS 
insertion  somewhere  in  its  life  cycle.  This  distribution  is  only  an  estimate  to  achieve  a 
rough  order  of  magnitude  regarding  the  COTS  distribution  out  in  our  fielded  systems. 
The  percent  of  programs  which  will  have  less  than  25%  COTS  should  be  about  -  15%  of 
the  programs.  The  percent  of  programs  which  will  have  greater  than  25%  but  less  than 
50%  COTS  should  be  about  -  7%  of  the  programs.  The  percent  of  programs  which  will 
have  greater  than  50%  but  less  than  75%  COTS  should  be  about  -  39%  of  the  programs. 
The  percent  of  programs  which  will  have  greater  than  75%  COTS  should  be  about  -  39% 
of  the  programs.  Using  this  estimated  distribution  and  applying  it  against  all  Navy 
acquisition  programs  the  expected  market  size  and  associated  distribution  is: 
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%  COTS 

%  Programs 

Number  of  Navy  Programs 
expected  to  be  within 
distribution  defined,  Assumes 
total  programs  as  365 

Assume  a  20%  Program 
Capture  Rate,  yields  the 
following  number  of 
programs  to  service 

<  25% 

15% 

55 

11 

25%  < 

50% 

7% 

26 

5 

50%  < 

75% 

39% 

142 

28 

>  75% 

39% 

142 

28 

Appendix  D  Table  4:  Target  Market 


Assuming  a  20%  capture  rate  of  the  potential  market  with  the  given  distribution 
and  assuming  the  programs  are  all  medium  size  programs  we  can  apply  our 
implementation  experience  with  the  SSB  system  to  estimate  the  amount  of  potential 
man/year  funding  possible.  Based  on  the  stated  assumptions  our  experience  shows  that  if 
the  evaluated  system  is  <  25%  COTS  then  it  would  translate  into  approximately  Vi 
man/year  of  work.  If  the  system  is  between,  25%  -  50%  COTS  it  would  translate  into 
approximately  %  man/year.  For  any  programs  having  50-75  %  COTS,  the  work  effort 
translates  into  about  1  man/year.  If  the  COTS  content  is  greater  than  75%  the  work  effort 
is  about  1  %  man/years.  This  rough  approximation  yields  the  following  expected  target 
market  size: 


Target  Market  Size  =  (#  programs,  <25%  COTS)  (.5)  +  (# 
programs,  25-50%  COTS)  (.75)  +  (#  programs,  50-75  %  COTS)  (1) 

+  (#  programs,  >  75%  COTS)  (1.5) 

Target  Market  Size  =  (11)  (.5)  +  (5)  (.75)  +  (28)  (1)  + 
(28)  (1.5)  =  79.25  man/year  per  year 

Time  Frame: 

Fiscal  Years  -  FY03  through  FY06 

Responsible  unit/person: 

The  SSB  Integrated  Product  Team  (IPT),  NSWC  Corona 
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Relationship  to  SWOT: 

•  Life  Cycle  Cost  (LCC)  reductions  of  as  much  as  50%  on  all  systems 
depending  on  program  constraints. 

•  Provide  the  Fleet  user  with  the  assurance  that  their  system  will  be  supportable 
over  time  and  available  when  needed. 

•  The  greater  the  use  of  the  system  the  greater  the  leverage  to  be  gained,  thereby 
expanding  its  value  proposition  to  the  Navy. 

•  Simulation  and  modeling  tools,  optimize  the  business  planning  and  identify 
future  support  requirements. 

B.  MARKETING  GOAL  B 

Project  an  Image  showing  symbiotic  nature  of  the  SSB  system  with  the  Tech 
refresh/insertion  efforts. 

Objective  Bl: 

Prepare  presentation  materials  and  reports  to  link  the  captured  metrics  (LCC 
reductions,  risk  management,  long-term  supportability)  regarding  the  SSB  system’s 
implementation  with  information  provided  from  the  affected  programs  on  the  SSB 
system’s  ability  to  support  tech  refresh/insertion. 

Specific  and  Measurable  outcome: 

For  each  program  that  implements  the  SSB  system  the  following  set  of  data  will 
be  captured  or  recorded: 

The  total  LCC  reduction  comparing  SSB  system  bottom  line  versus  Life  of  Type  Buy 
(LTB)  bottom  line. 

The  total  cost  avoidance  due  to  SSB  system  mitigating  the  necessity  for  redesign. 

Assessment  of  the  accuracy  of  the  predicted  versus  actual  costs  and  impacts  due  to  SSB 
system  implementation. 

Survey  of  customer  satisfaction  with  regard  to  the  SSB  implementation  efforts 

Interview  with  customer  then  prepare  a  structured  report  covering  implementation 
experience  and  lessons  learned. 

A  summary  assessment  of  the  implementation  effort  prepared  by  the  SSB  systems 
implementer  and  the  supporting  SSB  IPT. 

A  summary  report  will  be  prepared  for  each  program  evaluating  and  reporting  all 
data  gathered.  All  summary  reports  will  be  combined  and  analyzed  for  trends,  common 
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threads,  exceptional  areas  (good  and  bad),  and  effectiveness  of  implementation.  Both 
types  of  reports  will  be  prepared  for  publication  and  available  upon  request. 

Time  Frame: 

Reporting  information  will  be  collected  and  a  report  prepared  within  one  quarter 
after  the  close  of  FY03  and  repeated  every  year  thereafter. 

Responsible  unit/person: 

The  SSB  IPT  leader 

Relationship  to  SWOT: 

The  greater  the  use  of  the  system  the  greater  the  leverage  to  be  gained,  thereby 
expanding  its  value  proposition  to  the  Navy. 

•  Requires  a  cultural  shift  from  an  independent  competitive  environment  to  a 

collaborative  interdependency. 

•  New  system  with  a  very  small  track  record. 

•  Up-front  PMO  support  and  long-tenn  commitment  on  behalf  of  the  PMO  and 

the  support  team. 
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VI.  MARKETING  STRATEGIES 


A.  SEGMENTATION  &  DIFFERENTIATION 

Segmentation:  The  first  tier  of  segmentation  is  at  the  Market  level.  For  our 
services  and  products  the  appropriate  segment  at  the  Market  level  is  the  Niche  Marketing. 
The  particular  niche  market  is  specific  to  Navy  programs  with  a  need  to  support  their 
systems  that  contain  COTS  products.  The  criteria  that  can  be  applied  to  our  niche 
market,  which  forms  the  basis  for  differentiation,  can  be  described  using  three 
independent  attributes,  which  are  critically  important  to  the  customer.  The  specific 
characteristics  that  define  these  attributes  are:  Life  Cycle  Cost  (LCC)  impact, 
obsolescence  risk  management,  and  Long-term  supportability  attributes.  Table  5  below 
identifies  the  primary  methods  employed  by  DoD/Navy  DMSMS  support  teams/groups. 
The  position  of  the  SSB  system  relative  to  these  established  practices  and  a  few  other 


commonly  used  methods  are  discussed  in  subsequent  paragraphs  to  illustrate  the 
differentiation  exhibited  by  the  SSB  system  with  respect  to  the  established  practices. 


Resolution 

LOW 

AVERAGE 

HIGH 

($) 

($) 

($) 

Existing  Stock 

0 

0 

0 

Reclamation 

629 

1,884 

3,249 

Alternate 

2,750 

6,384 

16,500 

Substitute 

5,000 

18,111 

50,276 

Aftermarket 

15,390 

47,360 

114,882 

Emulation 

17,000 

68,012 

150,000 

Redesign —  Minor 

22,400 

111,034 

250,000 

Redesign —  Major 

200,000 

410,152 

770,000 

Appendix  D  Table  5:  Alternatives  Cost  Matrix  [16)  DMEA] 


In  addition  to  these  8  categories  of  alternatives  listed  in  Table  5,  the  Department  of 
Defense  DMSMS  Working  Group  [24)  DoD]  defines  three  other 
commonly  used  methods: 

•  Redefine  Requirement  to  Accept  Commercial  Item 

•  Life  of  Type  Buy  (LTB)  -  also  known  as  Life  Time  Buy  or  Bridge  Buy 

•  Reverse  Engineering  (RE) 
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Combining  all  these  alternatives  (including  the  SSB  system)  and  applying 
experience  and  engineering  judgment  we  will  assign  values/labels  for  the 
measurable  criteria  using  the  following  parameters: 

•  Risk  -  High,  Medium,  Low  -  to  identify  that  once  this  resolution  method  is 

used  it  carries  with  it  an  amount  of  risk  of  being  problematic  or 
unsuccessful 

•  Cost  -  $$$$  (most  expensive),  $$  (mid  range  cost),  $  (low  LCC)  -  Unlike  the 

point  solution  cost  shown  in  Table  5,  the  cost  identified  here  is  impact  to 
Life  Cycle  Cost  (LCC)  which  may  or  may  not  be  the  least  expensive 
initial  cost,  for  example  and  alternative  part  may  be  found  but  that 
resolution  may  be  short  lived  whereby  within  a  few  years  another 
alternative  part  needs  to  be  identified,  paid  for  and  implemented. 

•  LTS  -  Long-term  supportability,  LT  (long  tenn  >10  years),  MT  (Mid  Tenn 

5-7  years),  ST  (Short  Term  <5  years),  these  values  are  based  on 
engineering  judgment  and  experience. 

The  alternative  of  “Existing  Stock”  is  not  considered  as  an  alternative  because  if 
stock  currently  exists  and  there  is  a  shortage,  other  alternatives  will  be  used  to  mitigate 
the  issue  (i.e.  LTB).  The  remaining  alternatives  are  assigned  the  following  attributes: 


Alternative  Type 

Risk 

Cost  (LCC) 

Supportability 

(LTS) 

SSB  system 

L 

$ 

LT 

Life-of-Type  (LOT)  Buy 

L-M 

$$ 

LT 

Reclamation 

M 

$$ 

ST 

Alternate  Source 

L-M 

$ 

MT 

Substitute 

M 

$ 

MT 

Aftermarket 

M-H 

$ 

MT 

Redefine  Requirements 

H 

$$ 

MT 

Emulation 

H 

$$ 

ST 

Redesign  -  Minor 

M-H 

$$$$ 

MT 

Reverse  Engineering 

H 

$$$$ 

ST 

Redesign  -  Major 

M 

$$$$ 

LT 

Appendix  D  Table  6:  Positioning  and  Differentiation  Table 
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Positioning  &  Differentiation 
Of  Support  Alternatives 


Low 

Risk  Sunset- 


Short 

Term 


Risk 


$$  0  $ 

Financial  Impact 


Appendix  D  Figure  5:  Positioning  &  Differentiation  of  Support  Alternatives 

B.  TARGETING  &  POSITIONING 


1.  Resolution  Type  &  Positioning  Justification 
SSB  System 

A  method  to  extend  the  life  cycle  of  an  assembly  using  a  Systems  Engineering 
approach  to  manage  the  obsolescence  risk  inherent  in  COTS  products  and  provide  long¬ 
term  support  of  fielded  systems. 

•  Risk  -  Establishes  risk  management  methods,  processes,  and  tools  to  provide 

Low  Risk  to  the  program’s  systems.  Low  Risk  -  L 

•  Cost  -  Uses  business  and  management  processes  and  practices  to  partner  with 

the  OEM  and  supplier  community  to  constrain  the  LCC.  Low  Cost  -  $ 
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•  Supportability  -  Provides  an  overarching  Systems  Architecture,  which  enables 

long-term  support.  Long  Tenn  -  LT 

Life-of-Type  (LTB)  Buy  (also  referred  to  as  LOT) 

The  OEM,  its  distributors,  or  aftennarket  suppliers  may  have  enough  inventory  to 
meet  the  projected  demands  of  the  supported  equipment  for  the  rest  of  its  operational 
lifetime  or  may  continue  to  produce  the  component  for  a  specified  amount  of  time.  [16) 
DMEA] 

•  Risk  -  The  LTB  Buy  requires  a  good  deal  of  upfront  investment  which  if  not 

used  will  be  wasted,  this  is  especially  risky  if  and  when  the  program 
requirements  are  altered  and  equipment  configurations  changed.  Risk  to 
the  financial  health  of  the  program  and  potential  lack  of  flexibility  in 
meeting  future  program  requirements.  Risk  -  L-M 

•  Cost  -  Large  initial  investment  at  the  very  beginning  of  the  program  system 

life  cycle  and  potential  large  impact  to  LCC  if  program  requirements  are 
altered.  Mid  Range  Cost  -  $$ 

•  Supportability  -  Even  though  the  LTB  Buy  alternative  requires  large  upfront 

costs  the  long-term  supportability  is  very  good  provided  that  no  changes  in 
requirements  are  experienced.  Long  Tenn  -  LT 

Reclamation 

The  component  may  be  available  from  surplus  inventory;  from  equipment  that  is 
beyond  economical  repair,  is  in  deactivated  or  decommissioned  units,  or  was  removed  as 
part  of  a  modernization  program;  or  from  the  Defense  Reutilization  and  Marketing 
Service  (DEMS).  Some  refurbishment  or  testing  may  be  required. [16)  DMEA] 

•  Risk  -  This  point  solution  usually  entails  incorporating  a  part  of  unknown 

origin  and  using  it  in  a  functioning  system,  such  things  as  MTBF,  previous 
stressful  environments,  and  current  component  condition  present  the  new 
system  with  undefined  risks.  The  process  of  reclaiming  the  part  may 
further  deteriorate  the  component  adding  other  undisclosed  risks.  Medium 
Risk  -  M 

•  Cost  -  The  cost  of  reclaiming  parts/assemblies  is  expensive  not  only  because 

of  the  process  but  also  because  of  the  detailed  documentation  and  testing 
necessary.  Mid  Range  Cost  -  $$ 

•  Supportability  -  Reclamation  is  a  point  solution  usually  used  a  last  result  in 

making  up  some  short-gaps  in  the  supportability  of  the  fielded  system. 
Long  Term  -  LT 
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Alternate  Source 


If  part  specifications  and  test,  acceptance,  and  related  technical  data  are  complete 
and  available,  an  evaluation  of  the  manufacturer  production  capabilities,  tooling,  test 
programs,  etc.,  must  be  accomplished  to  ensure  the  ability  to  meet  the  original  item 
specification  requirements.  [24)  DoD] 

•  Risk  -  The  risk  involved  with  establishing  an  Alternate  Source  is  primarily  the 

technical  risk  accompanying  technology  transfer.  Potential  perfonnance 
risk  to  fielded  system.  Risk  Low  -  Medium  -  L-M 

•  Cost  -  Technology  transfer  if  done  well  can  be  accomplished  at  low  cost 

although  set-up,  testing,  and  qualification  may  vary  in  their  impact  to  the 
overall  cost.  Low  Cost  -  $ 

•  Supportability  -  Depending  on  the  purpose  for  the  technology  transfer  and  the 

associated  supplier  relationship  the  support  requirements  for  the  Alternate 
Source  are  typically  used  for  mid  term  needs  but  could  be  extended  to 
meet  long-term  requirements.  Mid  Term  -  MT 

Substitute 

It  may  be  possible  to  use  a  similar  component  with  an  acceptable  number  of 
design  differences  that  will  not  degrade  the  perfonnance  of  the  equipment.  [16)  DMEA] 

•  Risk  -  The  risk  involved  in  using  a  substitute  part  is  mostly  technical, 

essentially  the  way  the  new  part  responds  to  the  fielded  system  and  visa-a- 
versa,  many  times  it’s  response  is  an  unknown  until  fully  exercised  and 
tested  in  the  system.  This  mid  range  risk  is  considered  slightly  less  than 
the  Alternate  Source  because  the  OEM  for  the  substitute  part  has  a  history 
with  manufacturing  and  testing  the  part  so  they  understand  the  parts 
capabilities.  Medium  Risk  -  M 

•  Cost  -  With  regard  to  LCC  the  resolution  is  usually  as  simple  as  picking  a  part 

already  in  production  then  paying  to  have  it  tested  and  qualified  for  the 
application.  Low  Cost  -  $ 

•  Supportability  -  The  substitute  part  has  it’s  own  life  cycle  and  the  expectation 

that  this  part  also  may  go  obsolete  and  therefore  categorizes  a  substitute 
part  a  point  solution  that  may  or  may  not  last  the  life  cycle  of  the  fielded 
system.  Mid  term  -  MT 

Aftermarket 

Manufacturers  sometimes  buy  discontinued  production  lines  to  maintain 
component  production,  or  suppliers  buy  quantities  of  components  that  are  obsolete  and 
store  them  for  future  sale.  [16)  DMEA] 
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•  Risk  -  The  issues  which  arise  from  implementing  an  Aftermarket 

Manufacturer  are  problems  and  risks  that  become  evident  due  to  a  lack  of 
adequate  processes,  specifically:  Technology  Transfer  processes  not 
addressing  technical  issue,  business  processes  not  addressing  the  OEM  or 
Aftermarket  Manufacturer  needs  (i.e.  contractual  issues),  and  Program 
Management  processes  not  providing  adequate  up-front  planning.  Unless  a 
Systems  Engineering  approach  is  taken  to  address  these  risks,  the 
successful  transfer  of  the  technology  is  at  best  at  high  risk.  Medium  - 
High  Risk -M-H 

•  Cost  -  The  impact  to  the  LCC  using  this  alternative,  if  accomplished 

correctly,  is  low  and  even  if  the  technology  transfer  has  problems  the 
Aftermarket  Manufacturer  usually  is  stuck  with  most  of  the  costs.  Low 
Cost  -  L 

•  Supportability  -  The  part  once  transferred  is  not  necessarily  protected  against 

the  obsolescence  risk  issues  prevalent  in  COTS  products.  This  exposure 
will  eventually  lead  to  a  short-fall  in  providing  adequate  supportability 
over  the  life  cycle  of  the  fielded  system.  Mid  Term  -  MT 

Redefine  Requirements 

The  process  is  similar  to  the  substitution  alternative,  except  you  are  redefining  the 
item  to  accept  a  commercial  item  already  available,  instead  of  finding  an  item  which  is 
similar  to  the  DMSMS  item.  [24)  DoD] 

•  Risk  -  Although  the  technical  process  of  evaluation  may  be  the  same  the 

impact  to  risk  is  completely  different.  Changing  the  systems  requirements 
has  a  large  risk  associated  with  it  because  of  the  unknown  perturbations 
and  unintentional  consequences  that  may  result.  Additionally  the 
changing  of  the  system  specification  is  another  process  that  injects  added 
business  and  programmatic  risks  into  the  scenario.  This  alternative 
represents  a  high  risk  to  the  program  and  fielded  system.  High  Risk  -  H 

•  Cost  -  The  impact  to  the  LCC  will  be  due  in  part  to  the  defining, 

implementing,  qualification  and  testing  of  the  new  part  and  in  part  because 
the  business  and  programmatic  processes  will  need  to  be  altered  or  used 
and  therefore  must  be  funded.  Mid  Range  Cost  -  $$ 

•  Supportability  -  Like  the  substitute  part,  this  new  part  with  redefined 

requirements,  has  it’s  own  life  cycle  and  the  expectation  that  this  part  also 
may  go  obsolete  and  therefore  categorizes  a  the  part  as  a  point  solution 
that  may  or  may  not  last  the  life  cycle  of  the  fielded  system.  Mid  Term  - 
MT 
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Emulation 


A  government  or  industry  laboratory  may  have  developed  or  have  the  capability 
to  develop  an  F3I  (Form,  Fit,  Functional)  -  compatible  replacement  that  matches  the 
obsolete  component.  [16)  DMEA] 

•  Risk  -  The  technical  and  applications  risks  are  mid  to  high  when  employing 

emulation.  Not  all  the  technical  risks  are  evident  when  first  designing, 
fabricating,  and  testing  the  emulated  part  and  therefore  a  medium  risk. 

The  application  the  part  will  be  put  into  will  not  have  all  potential 
parameters  defined  and  many  times  critical  parameters  cause  failures  in 
the  application  and  are  totally  unexpected  resulting  in  a  high  risk  in 
integrating  into  the  application.  High  Risk  -  H 

•  Cost  -  Emulation  carries  with  it  a  fairly  substantial  price  because  it  is  an 

engineering  design  function  just  at  a  lower  functional  level,  it  therefore 
must  be  funded  appropriately.  The  impact  to  the  LCC  may  be  significant 
over  time  since  the  emulation  is  a  point  solution  that  may  need  to  be 
repeated  over  the  system  life  cycle.  Mid  Range  Cost  -  $$ 

•  Supportability  -  Like  the  substitute  part,  this  new  part  is  specific  to  this 

unique  application  and  has  it’s  own  life  cycle  and  the  expectation  that  this 
part  also  may  go  obsolete  and  therefore  categorizes  a  the  part  as  a  point 
solution  that  may  or  may  not  last  the  life  cycle  of  the  fielded  system. 
Emulation  exacerbates  the  life  cycle  issue  in  that  it  is  specifically  made  for 
the  application  and  therefore  cannot  leverage  off  of  other  applications  to 
keep  the  obsolete  parts  supported.  Short  Term  -  ST 

Redesign  -  Minor 

The  equipment  may  need  to  be  redesigned  to  accept  alternative  components  (e.g., 
a  new  layout  of  the  circuit  board).  If  no  other  resolution  is  cost-effective,  a  new  design 
may  be  necessary  to  completely  replace  the  obsolete  component.  [16)  DMEA]  Although 
both  minor  and  major  redesign  efforts  are  given  the  same  definition  by  DMEA  the  two 
are  differentiated  by  the  level  of  indenture.  The  minor  redesign  typically  deals  with  either 
a  component  on  a  lower  level  of  assembly  or  the  lower  level  assembly  itself.  The  major 
redesign  efforts  encompass  such  areas  as  significant  impacts  to  software,  interoperability, 
or  some  dependent  interaction  with  the  system  as  whole. 

•  Risk  -  The  technical  and  applications  risks  must  be  combined  with  business 

(e.g.,  contracts,  funding  profiles,  PPBS,  etc.)  and  Program  Management 
(i.e.  Configuration  Management  (CM),  ILS,  scheduling,  funding 
allocation,  etc.)  processes  as  part  of  the  risk  scenario.  Although  it  must  be 
pointed  out  that  a  minor  redesign  will  carry  with  it  a  smaller  impact  and 
therefore  lower  risk  than  a  major  redesign.  Medium  -  High  Risk  -  M-H 
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•  Cost  -  On  our  crude  scale  of  impact  to  LCC  both  minor  and  major  redesigns 

carry  the  same  identifier  even  though  the  costs  between  the  two  types  are 
vastly  different.  Most  Expensive  -  $$$$ 

•  Supportability  -  Important  to  note  is  that  the  major  redesign  should  result  in  a 

fairly  robust  long-tenn  supportability  of  the  fielded  system.  The 
expectation  is  that  the  designers  are  required  to  take  into  account  the 
system  supportability  issues  when  redesigning  the  system.  However, 
through  our  implementation  experience  with  the  SSB  on  COTS  products, 
we  found  that  most  every  major  and  minor  redesign  had  obsolescence 
issues  even  before  being  incorporated  into  the  system.  Therefore  major 
redesign  reflects  the  same  mid  term  supportability  as  is  the  case  with 
minor  redesign.  On  the  other  hand,  a  minor  redesign  by  definition  is 
constrained  to  a  lower  level  of  indenture  and  will  not  look  at  overall 
system  supportability  since  it  is  out  of  scope  for  the  effort.  The  minor 
redesign  therefore  has  the  potential  of  being  affected  by  system  impacts 
decreasing  it’s  long-term  supportability  to  somewhere  just  above  the  mid 
range.  Mid  Term  -  MT 

Reverse  Engineering 

An  exact  replica  of  the  component  may  sometimes  be  developed  by 
disassembling  and  analyzing  the  component;  developing  design  data  through 
measurement,  testing,  and  destructive  evaluation;  producing  coordinate  measurement 
machine  (CMM)  documentation  of  the  component;  conducting  technology  insertion 
reviews;  developing  and  verifying  technical  data  packages;  and  perfonning  first  article 
inspection  and  testing.  [16)  DMEA] 

•  Risk  -  The  technical  and  applications  risks  must  be  combined  with  business 

(e.g.,  contracts,  funding  profiles,  PPBS,  etc.)  and  Program  Management 
(i.e.  CM,  ILS,  scheduling,  funding  allocation,  etc.)  processes  as  part  of  the 
risk  scenario.  Reverse  Engineering  is  an  alternative  of  last  resort  because 
it  many  times  fails  completely.  High  Risk  -  H 

•  Cost  -  The  LCC  drivers  are  obvious  as  is  the  impact  to  the  program  but  if 

successful  the  program  will  have  in  its  position  the  ability  to  make  the  part 
for  as  long  as  needed.  Most  Expensive  -  $$$$ 

•  Supportability  -  The  Reverse  Engineering  alternative  is  not  only  costly  with 

high  risks  but  is  a  point  solution  for  a  very  specific  application.  This 
application  may  be  affected  by  other  parts  of  the  system  and  the  result 
may  render  the  effort  meaningless.  Only  if  the  remainder  of  the  system  is 
constrained  by  an  “Iron  Fisted”  CM  requirement  should  one  consider  this 
option.  Therefore  this  alternative  is  labeled  as  a  short-tenn  supportability 
alternative. 
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Redesign  -  Major  -  (see  Redesign  -  Minor) 

C.  TARGET  MARKETS 

The  target  markets  which  are  of  interest  to  us  are  those  PMOs  (customers)  that 
will  receive  the  most  benefit  by  implementing  the  SSB  system  thereby  building  on  our 
satisfied  customer  base.  Our  customer  base  will  be  a  subset  of  the  identified  365 
established  Navy  programs,  with  the  goal  of  capturing  20%  of  the  total.  Certain 
characteristics  of  a  program  will  enhance  the  potential  benefits  received  through 
implementation  of  the  SSB  system.  A  few  of  the  characteristics  we  will  focus  on  are: 
required  supportability  time,  fielded  system  life  cycle  phase,  criticality  of  fielded  system 
baseline,  total  number  of  COTS  units  fielded  systems.  The  required  supportability  time 
identifies  the  number  of  years  the  COTS  products  must  be  obtainable  to  install  new 
applications,  repair/replace  Fleet  returns,  and  maintain  fielded  systems.  The  preferred 
supportability  time  should  be  greater  than  5  years  as  measured  from  the  date  of  inclusion 
into  the  fielded  system  design.  The  reason  that  this  5  year  period  is  significant  is  because 
of  the  1.5-2  year  life  cycle  of  the  COTS  products  along  with  the  typical  support  period  of 
2-4  years  combined  together  will  support  the  fielded  systems  without  the  need  for 
extended  support.  The  fielded  system  life  cycle  phase  is  important  since  it  describes  the 
maturity  of  the  system,  which  in  turn  provides  an  indicator  of  the  current  supportability 
of  the  system.  The  sooner  in  the  life  cycle  the  better  with  regards  to  implementing  the 
SSB  system  and  if  given  a  choice  the  preferred  time  interval  would  be  within  10-15  years 
of  design.  After  this  10-15  year  period  more  and  more  of  the  supportability  solutions 
result  in  redesign  and  fewer  can  be  remedied  using  the  SSB  system.  Depending  on  the 
fielded  system  the  Configuration  Management  of  the  system  baseline  may  be  critically 
important  to  the  customer,  this  is  especially  true  when  dealing  with  certified  systems  (i.e. 
combat  weapon  system,  safety  system,  etc.)  Our  target  market  will  usually  have  some 
kind  of  constraint  regarding  the  system  baseline.  The  last  characteristic  to  look  for  with 
our  target  market  is  simply  common  sense  and  following  the  business  math,  in  essence 
the  more  volume  the  greater  potential  to  save  cost.  In  summary  our  “Target  Market”  can 
be  describe  by  the  following  attributes: 

•  Supportability  time  requirements  >  5  years  from  design/refresh  date 

•  Fielded  Systems  age  <  10-15  years  from  design/refresh  date 
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•  Customer  has  CM  constraints  for  fielded  system  baseline 

•  Look  for  programs  with  high  percentage  of  COTS  products. 

It  is  important  to  remember  that  the  above  listed  fielded  systems  characteristics 
are  not  constraints,  in  other  words  the  candidate  system  under  consideration  need  not 
have  any  of  these  characteristics  for  the  SSB  system  to  be  implemented.  However,  if  it 
were  Christmas  and  we  could  pick  and  choose  which  programs  to  go  after,  this  list  is  a 
good  starting  point  because  on  these  types  of  systems  the  SSB  system  returns  maximum 
results. 

D.  KEY  CUSTOMER  AND  COMPETITOR  REACTIONS 

What  are  the  likely  customer  and  competitor  reactions  to  marketing  mix?  How  does  the 
marketing  mix  give  us  a  competitive  advantage  in  serving  the  needs  of  the  target  market? 
Is  this  competitive  advantage  sustainable? 

The  SSB  system  has  been  designed  using  a  Systems  Engineering  approach 
whereby  the  sustainable  attributes  and  long-tenn  viability  were  taken  into  account  as  part 
of  the  system  requirements.  The  marketing  mix  reflects  this  long-term  viability  and 
addresses  each  of  the  4  P’s  (Product,  Pricing,  Distribution,  Promotion)  through  various 
actions  aimed  at  enhancing  the  marketability  of  these  designed  in  attributes.  The  SSB 
system  is,  to  the  authors  knowledge,  the  only  COTS  supportability  system  built  from  the 
ground  up  to  take  a  system  wide  life  cycle  view  using  a  Systems  Engineering  approach. 
In  essence  the  competitive  advantage  achieved  through  the  SSB  system  is  permanently 
embedded  into  the  methods,  processes,  and  tools  incorporated  into  the  System 
Architecture. 
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VII.  MARKETING  IMPLEMENTATION 


A.  STRUCTURAL  ISSUES 

The  Marketing  Plan  is  neither  an  independent  or  stand  alone  process/method, 
instead  it  is  embedded  as  an  integral  part  of  the  SSB  system  itself  such  that  a  marketing 
customer  focus  is  maintained  throughout  all  aspects  of  the  approach.  Especially  true  in 
the  product  development  phase.  Therefore  in  order  to  understand  the  marketing 
implementation  efforts  knowledge  of  the  SSB  systems  implementation  or  SEDI  is 
necessary.  The  Systems  Engineering  Development  and  Implementation  (SEDI)  plan  is 
one  of  four  foundational  documents  prepared  in  support  of  the  Sunset  Supply  Base  (SSB) 
system.  Although  the  SEDI  is  extensive  and  should  be  reviewed  for  a  complete 
understanding  the  following  description  illustrate  some  of  the  major  areas  in  which  the 
Marketing  Plan  must  interface.  The  purpose  of  the  SEDI  plan  is  to  put  into  perspective 
the  processes,  methods  and  tools  needed  to  implement  the  Sunset  Supply  Base  (SSB) 
system.  The  SEDI  plan  document  is  presented  as  a  “stand-alone”  prescriptive  set  of 
actions,  which  can  be  taken  in  the  establishment  of  an  SSB  system.  However,  the  SEDI 
plan  document  does  not  portend  that  it  is  the  only  process  or  method  to  establish  such  a 
system  but  instead  is  the  method  the  authors  have  chosen  to  implement  the  SSB  system. 
The  document  is  constructed  in  three  major  sections,  which  follow  a  brief  introduction  to 
the  SSB  system  concept.  The  primary  issues  grappled  with  in  the  SEDI  plan  are  those 
faced  during  implementation  and  encountered  primarily  when  bringing  the  idea  into 
reality.  The  first  section  of  the  SEDI  plan  addresses  introduction  to  the  program  and  the 
infrastructure  needed  to  support  the  effort,  such  areas  as:  teaming  structure,  computer 
resources,  communication  methods,  interface  with  the  programs,  data  structure 
requirements,  management  participation,  etc.  The  second  section  of  the  plan  covers  the 
implementation  of  the  SSB  system  and,  in  turn,  presents  many  challenges  to  overcome  in 
realizing  the  SSB  system.  The  final  section  of  the  plan  identifies  methods  and  metrics  to 
measure  the  impact  of  implementing  a  SSB  system,  thereby  providing  adequate 
indicators  for  the  programs  to  assess  the  effectiveness  and  value  proposition  in  using  the 
system. 


481 


B.  MARKETING  MIX 

Product 

The  SSB  system  provides  a  structured  set  of  processes,  methods,  and  tools 
embedded  in  a  System  Architecture  based  on  a  collaborative  framework.  Although  the 
SSB  system  yields  many  sub-products,  discussed  below,  this  Marketing  Plan  is  focused 
on  the  SSB  system  as  the  product  provided  to  the  customer  and  not  just  the  sub-products 
identified  herein.  The  SSB  system  employs  information  and  risk  sharing,  relationship 
building,  and  long-tenn  planning  to  yield  definable,  measurable,  and  reportable  impacts 
to  fielded  systems.  The  customers  (PMO  and  support  teams)  consider  both  the 
implementing  of  the  SSB  system  and  the  report  outputs  of  the  SSB  system  as  products. 
As  such,  the  implementing  processes  such  as  information  and  risk  sharing  directly  impact 
the  qualitative  output  assessments  like  the  obsolescence  risk  of  COTS  products  in  fielded 
systems.  The  customers  expectations  include  visibility  into  the  processes  and 
qualitative/quantitative  assessments  that  accurately  define  the  subsequent  output  of  the 
process.  To  meet  these  expectations  we  have  developed  the  following  implementation 
and  output  products: 

Implementation  Products  - 

Documented  17  Step  Process 

Prioritized  COTS  List  &  Vendor  Information 

Vendor  Status  Report 

Output  Products  - 

Obsolescence  Health  Report 

High  Risk  (RED)  Component  List 

Obsolescence  Impact  &  Purchase  Request  Report 

Assembly  Master  &  Cost  Matrices,  with  Definition  Worksheet 

The  implementation  products  provide  the  insight  to  the  customer  regarding  the 
qualitative  assessment  of  programmatic  risk  with  respect  to  the  relationship  building, 
information  sharing,  and  risk  management  practices  employed.  The  output  products 
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organize  the  data  and  information  gathered  then  assesses  the  potential  impacts  and 
recommends  proactive  actions  to  mitigate  programmatic  risks.  These  processes,  methods 
and  tools  are  quantitative  in  nature  and  are  presented  in  a  fonnat  to  provide  input  directly 
into  the  business  and  program  management  processes.  Collectively  these  products 
represent  new  knowledge  and  options  for  the  PMO  and  support  team.  Furthermore  the 
modeling  and  simulation  tools  give  the  decision  makers  the  opportunity  to  make  side-by- 
side  comparisons  of  different  potential  candidate  recommendations  prior  to  making  the 
final  decision.  As  identified  in  Figure  5  “Targeting  and  Positioning”,  the  SSB  system 
provides  exceptional  and  unmatched  customer  service  in  three  important  areas: 
obsolescence  risk  management,  Long-Term  Supportability,  and  Life  Cycle  Cost 
Reduction. 

The  products  themselves  are  designed  to  provide  unambiguous  bottom  line  LCC 
and  risk  assessments  and  present  the  results  in  easily  communicated  format.  The  reports 
from  one  program  application  can  be  aggregated  with  others  to  provide  a  composite 
picture  of  the  SSB  system’s  success  story.  The  reports  required  per  goal  and  objective 
“B”  were  defined  to  meet  this  aggregate/composite  success  story  in  order  to  help  define 
the  SSB  system’s  “Image”  as  -  Alternative  of  Choice  -  as  perceived  by  the  PMO  and  the 
support  teams.  This  reporting  mechanism  can  be  used  as  an  “Evergreen”  product  (i.e. 
constantly  be  updated  with  the  newest  infonnation)  to  promote  the  use  of  the  SSB  system 
and  placed  on  a  web  site  readily  available  to  the  DMSMS  community.  User  observations 
and  infonnation  have  and  will  be  used  to  develop  the  product.  Business  case  study 
results  will  be  used  to  further  perfect  and  build  the  product.  The  product  will  continue  to 
be  built  as  more  and  more  users  use  the  product  and  the  database  grows. 

Pricing 

The  pricing  of  our  services  and  products  will  need  to  be  estimated  and  identified 
in  a  proposal  to  the  PMO  specifically  tailored  to  the  application.  Rough  Order  of 
Magnitude  (ROM)  estimate  methods  were  suggested  early  on  in  this  plan  to  estimate 
market  size  and  to  set  marketing  goals.  These  ROM  estimates  assumed  that  the  identified 
programs  (see  Table  3)  were  approximately  the  same  size  as  the  SSDS  program  which 
has  about  115  different  unique  COTS  products  and  is  considered  a  medium  size  program. 
To  these  estimated  values  are  reiterated  here  so  if  no  other  method  is  available  at  lease  a 
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ROM  could  be  generated  to  get  the  process  going.  Based  on  the  stated  assumptions  our 
experience  shows  that  if  the  evaluated  system  is  <  25%  COTS  then  it  would  translate  into 
approximately  14  man/year  of  work.  If  the  system  is  between,  25%  -  50%  COTS  it  would 
translate  into  approximately  %  man/year.  For  any  programs  having  50-75  %  COTS,  the 
work  effort  translates  into  about  1  man/year.  If  the  COTS  content  is  greater  than  75%  the 
work  effort  is  about  1  !4  man/years. 

Another  way  to  look  at  the  pricing  issue  would  be  to  use  the  SSDS  MK  1  data  set 
and  estimates  of  support  resources  to  drive  an  average  cost  per  part  per  year.  Estimates 
for  the  MK  1  system  resource  support  covering  the  setup  and  long-term  support  for  89 
unique  items  over  a  ten  year  period  resulted  in  a  cost  of  $1,836.00  per  item  per  year. 
Since  this  value  is  derived  from  other  estimates  there  is  a  large  amount  of  uncertainty 
associated  with  the  accuracy  and  utility  of  the  number,  however  it  is  another  approach 
that  could  be  use  to  perfonn  estimating  efforts. 

Distribution 

The  SSB  system  comprises  several  processes  during  the  implementation  of  the 
concept.  As  identified  in  Figure  6  “Implementation  Process”,  a  relationship  building 
process  is  established  to  obtain  the  COTS  Component  Infonnation  from  the  Original 
Equipment  Manufacturer  (OEM)  for  analysis.  Arrangements  are  made  at  this  time  to 
involve  a  third  party  to  continue  manufacturing  the  products  if  the  OEM  chooses  not  to 
continue  making  the  products.  However  if  the  OEM  wishes  to  participate  by 
continuation  of  production  of  the  COTS  products  and  share  the  risk  of  stockpiling 
obsolete  parts,  then  the  dashed  box  in  Figure  6  identifies  the  scope  of  their  participation. 
The  component  infonnation  is  then  analyzed  for  obsolescence  risk  and  an  assessment  is 
provided  to  the  DMSMS  support  team  to  detennine  the  appropriate  action  plan. 
Typically  the  number  of  high  risk  parts  are  defined  along  with  an  estimated  quantity  of 
each  part  needed  to  support  the  program  fielded  equipment  for  a  prescribed  period  of 
time,  usually  until  the  next  tech  refresh/insertion.  These  parts  are  then  stocked  on  the 
OEM  or  third  parties  shelves  until  they  are  consumed  to  make  the  COTS  assemblies 
needed  in  the  Fleet.  Dependent  on  the  programs  needs  this  process  provides  long-term 
support  for  the  end  user,  the  Fleet. 
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Appendix  D  Figure  6:  Implementation  Process 


Appendix  D  Figure  7:  17  Step  Implementation  Process 

The  17  Step  Process  describes  the  detailed  sub-processes  needed  to  implement  the  SSB  system  and 
identifies  many  of  the  intermediary  products  used  by  the  PM  to  provide  visibility  into  the  process  are 
identified  here.  This  process  flow  illustrates  how  information  and  data  are  collected  and 
disseminated;  where  in  the  process  these  actions  take  place;  what  are  the  expected  outcomes  of  the 
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process;  and  who  is  expected  to  accomplish  which  tasks.  Below  is  a  definition  of  each  step  in  the 
process: 

Case  Opened:  Requires  initial  information  (BOM,  COTS  list,  etc). 

Step  1.0 

The  Program  Office  provides  the  indentured  Bill  Of  Materials  (BOM)  complete 
with  suppliers’  CAGE  codes  and  part  numbers,  to  NSWC  Corona  for  analysis.  The 
Commercial  Off  The  Shelf  (COTS)  products,  usually  at  the  assembly  level,  are  identified 
and  compared  against  the  current  SSB  database  to  identify  if  any  of  the  items  have 
already  been  placed  in  the  Sunset  Supply  Base  (SSB).  The  products  will  fall  in  one  of 
three  groups:  1)  Part  Number  at  the  assembly  level  is  already  placed  with  the  SSB,  2)  An 
SSB  relationship  is  set  up  but  not  for  assembly  in  question,  and  3)  No  SSB  relationship 
exists.  For  any  products  not  already  in  the  database  (groups  2&3),  the  Original 
Equipment  Manufacturer  (OEM)  -  COTS  Vendor  -  will  be  contacted  to  identify 
supportability  time  line  for  each  assembly,  additionally  parts  lists  along  with  an  outline 
drawing  at  the  assembly  level  will  be  requested  for  use  later.  Some  suppliers  prefer  to 
wait  until  assurances  are  provided  (such  as  a  Non-disclosure  agreement)  before  releasing 
this  information. 

Step  2.0  &  3.0 

A  health  analysis  (Red,  Yellow,  Green)  of  any  microcircuits  and  COTS 
assemblies  is  obtained  or  generated  to  identify  risk  and  set  priorities.  An  obsolescence 
report  is  developed  to  inform  the  PMO  of  known  obsolescence  issues  and  the  plan  of 
action  regarding  the  un-identified  risk  issues  with  regard  to  COTS  assemblies.  If  a  COTS 
assembly  exists  in  the  SSB  database  and  has  obsolete  parts,  a  coordinated 
recommendation  between  NSWC  Corona  and  the  PMO  or  support  agent,  will  be  made  to 
purchase  the  amount  of  obsolete  component  parts  necessary  to  support  the  expected 
future  orders  to  meet  the  programs  requirements.  These  piece  parts  will  be  bought 
through  the  SSB  supplier  who  will  then  store  them  on  his  shelf  until  consumed  through 
future  assembly  orders  from  the  program. 

Step  6.0 

After  signing  Non-Disclosure  Agreement  between  NSWC  Corona  and  OEM,  the 
list  of  components  on  the  COTS  assembly  of  interest  is  received  by  NSWC  Corona,  a 
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health  assessment  of  each  component  on  the  assembly  is  conducted  to  determine  status 
(red,  yellow,  green),  and  finally  an  assembly  level  health  assessment  report  is  issued. 

Step  7.0  &  8.0 

Program  Management  Office  or  support  agent  to  review  the  plan  of  action  and 
recommendations,  iterate  if  necessary,  task  NSWC  Corona  to  implement  the  plan  and 
provide  the  purchase  order(s)  to  the  appropriate  SSB  suppliers  to  mitigate  risk  to  specific 
COTS  assemblies. 

Step  4.0,  5.0,  and  9.0 

Based  on  experience  and  knowledge  of  the  SSB  supplier  and  the  OEM,  NSWC 
Corona  will  use  a  Systems  Engineering  approach  and  senior  Quality  Engineers  to  match 
the  two  companies  in  three  primary  areas:  performance,  technical  capabilities,  and 
Business  Practices.  Periodic,  in-plant,  formal  reviews  at  the  SSB  suppliers  facilities  will 
be  used  to  keep  a  current  assessment  of  these  three  areas.  Assessments  will  be  based  on 
the  IEEE  assessment  templates  and  other  industry  best  practices.  The  two  companies  will 
be  matched  but  since  this  is  a  collaborative  system  and  necessitates  voluntary 
involvement,  the  final  choice  of  teaming  partners  is  with  the  two  companies.  NSWC 
Corona’s  role  is  one  of  technical  assistance  and  facilitation.  A  contractual  agreement  is 
defined  by  and  implemented  through  the  two  companies,  a  Memorandum  of 
Understanding  (MOU)  may  be  used  encompassing  all  three  entities  to  facilitate 
communication. 

Step  10.0, 11.0, 12.0,  and  13.0 

These  steps  identify  major  milestone  activities,  which  must  be  accomplished 
successfully  to  establish  the  SSB  supplier  as  a  second  source  for  the  COTS  assembly. 
Transfer  of  the  technology  from  the  OEM  to  the  SSB  supplier  is  assisted  through  the 
technical  assistance  of  NSWC  Corona  Quality  Engineering  staff.  Facilitation  and 
coordination  with  the  Program  Office  and  other  involved  parties  (i.e.  In-Service 
Engineering  Agent  (ISEA),  field  activities,  procurement  agent,  etc.)  is  one  of  the  key 
functional  responsibilities  of  NSWC  Corona  and  during  this  transfer  process  NSWC 
Corona  will  perform  an  operational  and  capabilities  review  thereby  establishing  the 
original  baseline  assessment  of  the  SSB  supplier.  The  OEM  is  the  responsible  party  in  all 
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these  steps,  as  the  design  and  manufacturing  expert  and  owner  of  the  intellectual 
property,  they  (the  OEM)  have  a  vested  interest  in  assuring  the  successful  transfer  to 
substantiate  the  business  case. 

Step  14.0, 15.0, 16.0,  and  17.0 

The  full-scale  production  of  the  transferred  COTS  assembly  will  be  dependant 
upon  the  Navy’s  requirements  for  the  product.  Procurement  of  the  assemblies  will  take 
place  using  existing  methods  and  processes  but  be  directed  to  the  SSB  supplier  by  adding 
the  SSB  supplier  CAGE  code  as  an  alternate  manufacturer  in  the  procurement  system 
controls.  On  a  periodic  basis  an  obsolescence  report  will  be  generated  to  assess  the  on¬ 
going  risk  to  the  program  and  assess  if  component  parts  need  to  be  purchased  and  placed 
in  the  SSB  suppliers  inventory  to  support  future  build  requirements.  The  SSB  supplier 
will  provide  visibility  and  control  over  the  Navy  assets  in  their  inventory.  Periodic 
reviews  of  the  SSB  suppliers’  facilities,  operations,  business  practices,  manufacturing 
methods  and  quality,  will  be  accomplished  to  assure  the  long-term  viability  of  the  SSB 
suppliers,  providing  a  pro-active  risk  management  approach. 

When  evaluating  the  distribution  process  it  is  important  to  include  the  network 
and  partnerships  we  have  cultivated  through  implementing  the  SSB  system.  The 
collaborative  approach  we  have  taken  with  other  groups,  activities,  and  other  members  of 
the  community  has  yielded  several  partnerships  where  our  partners  have  identified  SSB 
system  opportunities  and  brought  us  the  work.  Conversely  we  have  been  tasked  by  PMOs 
to  accomplish  some  work  which  a  portion  of  the  work  another  activity  is  better  suited  to 
do,  so  in  this  case  we  bring  in  their  expertise  and  provide  the  funding.  Working  in  this 
manner  -  “I’ll  scratch  your  back  if  you  scratch  mine”  -  we  have  several  Navy  activities, 
OEMs,  and  contractors  suggesting  to  their  PMO  that  our  services  be  brought  in  to  help 
solve  the  issues  with  COTS  products.  Essentially  our  partners  are  working  as  our 
marketing  and  sales  force  and  they  do  it  because  it  makes  good  business  sense;  by 
incorporating  the  SSB  system  it  brings  greater  value  to  their  services  and  products  as 
perceived  by  their  customer. 

Promotion 

Who  is  our  audience  that  will  use  or  influence  the  use  of  the  SSB  system? 
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1)  Decision  Makers  -  Contractor  &  Government  -  [Early  Adopters] 

a.  Program  Manager 

b.  Design/Developers 

c.  Technology  Insertion  Managers 

d.  DMSMS  Support,  Policy  making  Community 

e.  Recourse  Sponsor 

2)  GateKeepers  /  middlemen  /  intennediaries  -  [Early  Majority  -  Late  Majority] 

a.  ILS  Manager 

b.  Procurement  Managers 

c.  DMSMS  Team  Lead/Managers 

d.  SYSCOM  Policy  Managers 

e.  Fleet  Support  Managers/ISEAs 

3)  Using  Community  -  [Innovators  -  Early  Adopters  -  Early  Majority] 

a.  Designer/Developer  -  Government  &  Industry 

b.  Software/Hardware  Integration  sites 

c.  End  Users  -  Fleet  &  Shore 

d.  DMSMS  Professionals,  Gov.  &  Industry 
Summary  of  overall  promotion  strategy: 

Each  of  the  segmented  consumers/influences  provided  above  will  have  a  tailored 
plan  crafted  to  meet  their  obsolescence  risk  needs  or  create  desire  for  the  SSB  system 
products.  Given  that  our  product  is  in  the  “Market  Introduction”  part  of  the  product  life 
cycle  and  quickly  headed  toward  a  “Market  Growth”  as  a  result  of  successful  initial 
implementation  efforts  on  three  Navy  programs,  provides  some  special  attributes,  a  fact 
that  will  and  should  be  evident  in  our  promotions.  Another  re-occurring  theme 
throughout  our  promotion  will  be  stressing  our  “Product  Leadership”  as  our  marketing 
strategic  direction.  This  direction  will  be  evident  through  the  emphasis  on  the  new  and 
unique  SSB  attributes  regarding,  Life  Cycle  Cost  reductions,  establishment  of  risk 
management  methods  and  business/PMO  flexibility  and  the  resulting  benefits  to  the 
adopters.  As  a  means  to  shift  our  target  segmented  consumer  base,  an  assessment  will  be 
made  to  their  current  position  with  respect  to  the  adoption  process  (i.e.  Awareness, 
interest,  evaluation,  trial,  decision,  or  confirmation),  then  identify  the  most  appropriate 
promotion  objective(s)  (Informing,  Persuading,  or  Reminding)  to  produce  the  desired 


489 


change,  by  eliciting  the  responses  evident  in  the  action-orientated  model  AIDA 
(Attention,  Interest,  Desire,  Action).  Finally  the  type  or  types  of  promotion(s)  (Personal 
Selling,  Mass  Selling,  Sales  Promotion,  Advertising,  Publicity)  will  be  utilized  to  elicit 
the  most  favorable  response. 

1.  Promotion  Plan  for  Group  1,  Decision  Makers 

The  evaluative  criteria  (i.e.  what  criteria  the  group  will  use  in  evaluating  the 
utility  of  the  SSB  system)  for  the  decision  makers,  Group  1  will  be  risk  management 
capability,  Life  Cycle  Cost  reduction  characteristics,  and  Long-tenn  supportability 
attributes.  Additionally  this  group  will  look  at  the  SSB  system  from  a  business 
perspective  by  evaluating  the  funding  profde  generated  through  the  use  of  the  system. 
These  criteria  are  graphically  displayed  in  Figure  8  showing  the  first  three  criteria 
described  and  Figure  9  illustrating  the  funding  profile  of  the  SSB  system  versus  the  Life 
of  Type  Buy  (LTB)  and  Refresh  alternatives. 
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Appendix  D  Figure  8:  Positioning  &  Differentiation  of  Support  Alternatives 
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Appendix  D  Figure  9:  Comparison  of  Funding  Profiles 


The  “Decision  Makers”  are  an  extremely  important  part  of  our  consumer  base. 
The  promotion  approach,  to  be  most  effective,  must  take  into  account  that  this  group,  as 
identified  by  market  research,  is  in  the  “Early  Adopters”  and  are  open  to  evaluating  new 
options  when  provided  the  choice.  Availability  of  potential  choices  must  be  made  base  on 
the  awareness  of  other  choices,  capturing  the  groups  interest  through  cost  benefit  analysis 
and  by  showing  that  evaluation  of  alternatives  will  yield  outstanding  benefits.  Therefore 
the  primary  promotion  objective  for  our  Decision  Maker  group  must  be  informing  to  get 
their  attention  and  spark  their  interest,  the  characteristic  of  being  in  the  Early  Adopters 
category  should  be  self-perpetuating  after  that.  The  following  marketing  activities  will 
initiate  our  offensive  to  capture  this  consumer  segment: 

Activity  1  -  Education  &  Enlightenment 
Conferences 


The  SSB  IPT  Team,  NSWC  Corona  (here  after  referred  to  as  the  SSB  Team)  will 
take  a  leadership  role  and  present  the  SSB  system  at  the  leading  conferences,  which  focus 
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on  the  Program  Manager,  Design/Developer  and  Technology  Insertion  communities.  A 
vendor  booth  in  the  Exhibit  Hall  where  our  advertising  pamphlets,  nic-nac  giveaways, 
and  free  software  on  CD  ROMs  can  be  combined  with  our  personnel's  face-to-face  time 
with  the  consumer  should  augment  this  type  of  publicity.  Although  the  approach  would 
be  identical  for  all  three  of  these  major  elements  of  the  group,  more  than  likely,  one  or 
two  separate  conferences  for  each  element  may  be  required,  [cost  -  $1000/day  for  3  days 
times  6  conferences  +  6  trips  @  $1500  per  trip  =  $27,000] 

Publications 

The  SSB  Team  will  author  and  sponsor  authorship  of  authoritative  articles  to  be 
strategically  placed  in  the  trade  publications  targeting  this  Decision  Makers  group.  These 
articles  will  be  provided  to  the  internal  Navy  publication  groups:  Defense  Acquisition 
University  (DAU),  Program  Manager  -  PM  Magazine,  DAU  -  Acquisition  Review 
Quarterly,  etc.,  at  the  same  time  and  identified  as  a  leading  edge  COTS  support  system. 
[Team  authored  -  cost  $4000  per  publication  external,  times  6  publishers,  times  4 
separate  articles  (provided  every  3  months)  =  $96,000  :  Sponsored  Authorship  -  cost 
$5000  to  author  times  4  separate  articles,  $4000  per  publication  external,  times  6 
publishers,  times  4  separate  articles  =  $116,000  :  Internal  publication  considered  free  of 
charge] 

Collaborative  Advertising 

In  concert  with  the  running  of  the  publications  identified  above  a  collaborative 
and  symbiotic  relationship  should  be  crafted  with  the  SSB  system  participants 
encompassing  the  entire  range  of  our  OEM  relationships  including  industry  leaders  like 
Motorola  and  DY4,  to  medium  and  small  size  companies.  The  collaborative  effort  would 
work  this  way  -  the  SSB  Team  would  underwrite  the  feature  article  and  surrounding  that 
article  the  industry  leaders/participants  will  buy  all  available  (within  reason)  advertising 
space  displaying  their  newest,  state-of-the-art,  COTS  supportable  products.  The  Navy 
will  be  perceived  as  part  of  the  industrial  supportability  solution  space  pushing  state-of- 
the-art  and  the  industry  leaders  will  be  marketing  to  the  Decision  Maker  group  in  the 
Navy.  The  Navy  will  need  to  be  directly  identified  in  the  article,  so  as  to  make  this 
connection  and  perhaps  the  industry  leaders  may  wish  to  also  identify  the  Navy 
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specifically  in  their  advertising,  [cost  -  Since  this  is  perceived  as  a  collaborative  effort 
minimal  cost  is  associated  with  this  approach] 

Activity  2  -  Influencing  Policy 

Point-Counter-Point 

The  SSB  Team  will  prepare  various  written  artifacts  such  as  “White  Papers”, 
articles,  letters  to  the  editor  and  reports  directed  at  current  policy,  illustrating  the  utility  of 
a  policy  endorsing  the  use  of  the  SSB  system  products.  These  written  artifacts  are  meant 
to  be  used  primarily  inside  the  Navy  in  internal  publications  pointed  specifically  at  the 
closed  community  of  policy  makers,  [cost  -  expected  to  be  minimal] 

Face-To-Face 

Since  the  group  of  policy  makers  is  relatively  small  although  somewhat  spread 
out,  regular  face  time  with  this  group  is  planned.  To  augment  these  visits,  high  profile 
individuals  of  the  SSB  system  community  (i.e.  industry  leader  VPs,  academia,  Presidents 
of  OEM  COTS  companies,  etc.)  will  be  requested  to  accompany  our  Teams  personnel  to 
meet  and  possibly  present  to  this  policy  making  group. [cost  -  $1500  per  trip  for  6 
requested  visitors  (travel  costs)  =  $9,000] 

On-going  Policy 

Policy  is  in  a  continuous  state  of  flux  with  changes,  re-writes  and  reviews  taking 
place  daily.  The  SSB  Team  will  become  part  of  the  technical  review  community  to 
champion  the  SSB  systems  approach  and  eventually  influence  downstream  policy,  [cost  - 
approximately  one  fourth  a  man  year,  $200,000/4  =  $50,000] 

Activity  3  -  Inform  Resource  Sponsors 
Money  Talks 

Since  the  Resource  Sponsors  provide  all  funding  spent  in  the  Navy  it  is 
imperative  that  the  benefits  of  SSB  system  products,  especially  reductions  of  Life  Cycle 
Cost  (LCC),  COTS  risk  management,  and  business/management  process  support,  get 
identified  to  this  group  as  often  as  possible.  This  group  is  also  responsible  to  make  sure 
the  needs  of  the  Fleet  are  met  in  a  cost  effective,  continuous  manner,  which  is  consistent 
with  the  priorities  they  have  identified.  The  attributes  of  the  SSB  system  and  its  products 
play  into  several  of  the  set  priorities  such  as  availability,  interoperability,  maintainability, 
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and  supportability  to  name  just  a  few.  The  SSB  Team  will  identify  the  set  of  priorities 
and  find  the  biggest  problem  areas  where  the  SSB  system  products  are  applicable,  then 
craft  potential  solutions  to  a  few  of  these  showing  how  the  priorities  will  be  met  and 
highlight  the  resulting  reduction  in  LCC.  The  report  should  be  presented  to  the  Resource 
Sponsor  community  as  an  example  of  potential  possibilities  and  how  with  the  “Right” 
policies  in  place,  the  effort  could  be  duplicated  and  implemented. [cost  -  one  third  of  a 
man  year  $200,000/3  =  $67,000] 

Independent  Assessment 

Identify  the  primary  informational  sources  research  the  Resource  Sponsors  use  as 
a  community  to  base  their  funding  resource  decisions  on  (i.e.  MIT  study,  GAO  report, 
Fleet  feedback,  expenditure  reports,  etc.).  Once  the  primary  infonnation  resources  are 
identified,  commission  an  independent  study  focusing  the  work  in  application  of  the  SSB 
system  to  solve  the  aforementioned  problems.  Direct  the  independent  assessment  to  focus 
on  and  use  the  informational  data  sources  the  group  usually  relies  on  as 
comparison/contrasting  base  information  with  the  outputs  of  the  SSB  system  evaluation. 
Provide  this  independent  assessment  report  to  the  Resource  Sponsors  community  using  as 
large  a  distribution  as  applicable  boldly  stressing  both  the  data  source  and  the 
independent  nature  of  its  generation. [cost  -  $125,000] 

Success  Stories 

Getting  success  stories  in  front  of  this  community  is  important  and  the  use  of  the 
usual  printed  publications  will  be  done  as  mentioned  above  to  illustrate  these  successes. 
However  to  make  a  more  lasting  impression  the  stories  need  to  be  told  in  a  more 
convincing  context.  The  SSB  Team  understands  that  the  Resource  Sponsor  community 
presents  regularly  to  various  audiences  to  get  the  word  out  on  their  initiatives  and 
priorities.  Since  the  Resource  Sponsor  will  already  be  present  at  these  meetings,  if  the 
speaker  just  prior  or  just  succeeding  his  or  her  presentation,  was  to  present  the  success 
story  of  the  month  resulting  from  the  SSB  system,  it  would  be  a  non-intrusive  way  to  get 
the  word  out.  [cost  -  expected  to  be  already  incorporated  in  conferences  above] 
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Authoritative  Show  &  Tell 


Prepare  a  presentation  to  give  to  the  entire  community  during  their  annual 
meeting  conference.  Co-present  the  material  with  a  very  well  respected  industry  leader 
like  a  prime  contractor,  OEM,  and  other  SSB  participants  focusing  in  on  the  impact  to 
these  entities  while  touching  on  the  communities  needs  and  priorities.  The  proceedings 
and  the  presentation  will  be  published  and  provide  a  documented  resource  to  the 
community. [cost  -  see  conferences  above] 

Activity  4  -  Address  NAVICP  Contracting  Policies  Threat 
The  Direct  Approach 

As  identified  in  the  SWOT  analysis  the  threat  created  by  the  implementation 
policies  put  in  place  by  NAVICP  can  be  dealt  with  using  several  avenues.  The  preferred 
approach  is  to  provide  the  NAVICP  leadership  with  the  analysis  presented  in  this  plan, 
then  work  collaboratively  with  them  to  modify  the  current  policy.  To  initiate  this 
approach  will  require  first  finding  the  right  group  of  decision  makers  to  present  the 
information  to.  Once  identified  the  decision  makers  will  be  provided  the  infonnation  to 
study  prior  to  a  face-to-face  meeting.  The  face-to-face  meeting  will  be  important  in 
gaining  credibility  and  expedite  information  exchange  and  communication.  As  part  of 
the  logical  argument  in  substantiating  the  claims  made  in  the  analysis  a  presentation  on 
the  SSB  system  will  illustrate  the  potential  gain  to  the  Navy  through  changing  the  current 
policies.  Included  in  the  material  presented  will  be  the  methodologies  and  results  from 
the  Business  Case  Analysis  (BCA)  which  should  be  of  special  interest  to  the  NAVICP 
audience.  Furthermore  special  examples  of  successful  implementation  efforts  showing 
how  the  government  unique  position  yields  positive  attributes  for  the  Navy  that  are 
unobtainable  if  attempted  through  a  contractor.  The  issue  of  “conflict  of  interest”  should 
also  be  addressed  through  the  presentation  materials  showing  specific  examples  based  on 
implementation  experience.  The  expectation  of  this  meeting  has  a  lot  a  variability 
ranging  from  being  thrown  out  of  the  office  to  NAVICP  embracing  the  SSB  system  as  a 
preferred  alternative,  [cost  -  $1500  per  trip  for  1  trip  (travel  costs)  =  $1,500] 
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The  Customer  Request  Approach 

Identify  one  of  the  programs  that  have  a  requirement  to  place  their  next  contract 
on  a  Performance  Based  Contract  (PBC)  or  a  Performance  Based  Logistic  (PBL)  contract 
with  a  contractor  and  is  willing  to  implement  the  SSB  system.  Partner  with  the  program 
in  addressing  the  issues  threatening  the  use  of  the  SSB  system.  The  meeting  format  is  as 
described  as  above  but  with  the  additional  inputs  from  NAVICP’s  customer  the  PMO. 
[cost  -  $1500  per  trip  for  1  trip  (travel  costs)  =  $1,500] 

Reporting  Up  the  Chain  of  Command  Approach 

This  approach  can  be  used  in  parallel  with  either  of  the  approaches  listed  above  or 
accomplished  independently.  As  describe  earlier  in  this  plan  the  issues  will  be  presented 
in  a  concise  written  format  and  forwarded  to  ASN  for  review,  interpretation  and  possible 
intervention.  Once  the  actions  are  accomplished  by  ASN  the  expected  next  steps  will 
depend  on  the  ASN’s  findings.  If  the  answer  comes  back  with  “No  Policy  Change 
Needed”  then  other  avenues  need  to  be  addressed  (i.e.  Direct  Approach,  focus  on 
program  relationships,  etc.).  Should  ASN  agree  that  “Yes  a  Policy  Change  is  Needed” 
then  the  next  step  will  depend  on  how  much  involvement  ASN  will  have  in  making  the 
necessary  changes.  One  possibility  is  that  they  take  the  lead  and  request  NAVICP  make 
appropriate  changes  independent  of  our  involvement.  Another  possibility  is  to  respond  to 
our  request  directly  back  to  us  with  a  written  interpretation  and  we  at  that  point  would 
need  to  work  out  the  details  with  NAVICP  in  changing  the  policy.  The  impact  of  the 
NAVICP  policies  is  so  large  that  to  do  nothing  will  be  detrimental  to  the  SSB  system 
acceptance.  The  impact  justifies  the  risk  in  making  the  request  and  attempting  to  change 
the  current  policies. [cost  -  no  cost  impact  in  making  the  request  considered  a  part  of  staff 
nonnal  function] 

2.  Promotion  Plan  for  Group  2,  GateKeepers  /  Middlemen  / 
Intermediaries 

The  evaluative  criteria  for  Group  2  are  1)  meeting  the  PM  expectations  as 
illustrated  in  Figures  8  &  9,  2)  a  process  that  is  easy  to  use,  3)  provides  solutions  which 
take  into  account  the  time  dependency  of  the  solution  space,  4)  generally  this  group  is 
looking  for  quick  returns  to  capitalize  on  the  success  for  personal/professional  gain. 
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This  group  represents  the  implemented  of  other  groups  policies  and  initiatives,  as 
such,  this  group  tends  to  take  a  “wait  and  see”  or  “  let  someone  else  test  the  waters” 
thereby  entering  the  market  cycle  much  later,  participating  as  Early  Majority  -  Late 
Majority.  Meeting  goals  and  objectives  of  their  command  structure  takes  priority  in 
accomplishment  of  their  function  and  the  less  risky  the  method  the  better,  since  the 
establishment  has  as  its  foundation  a  risk  avoidance  mentality.  Continuous  personnel 
movement  through  these  positions  produces  high  turn  over  rate  and  therefore  the  people 
in  these  positions  focus  on  the  quick  return  on  their  efforts.  The  use  of  the  Persuading 
strategy  as  the  promotional  objective  will  be  most  effective  when  coupled  with  personal 
selling  (Face-to-Face)  and  potentially  the  use  of  Sales  promotions.  However  in 
government  business  activities  the  Sales  promotions  are  a  bit  different  than  implemented 
in  the  commercial  industry.  The  Sales  promotion  here  is  more  of  a  marketing  of  the 
accomplishment  or  work  done  by  the  specific  person  one  is  interacting  with,  for  example 
a  success  in  implementing  the  SSB  system  will  be  advertised  in  the  SSB  Team  newsletter 
to  all  the  Navy  Program  Offices  and  Resource  Sponsors,  with  special  attention  to 
highlight  the  implementing  personnel  with  name,  position,  quotes  and  picture.  Using  this 
approach  we  provide  a  promotional  method  to  enhance  the  personal  value  or 
marketability  of  the  involved  personnel. 

Activity  1  -  Newsletter 

The  SSB  Team  will  define  a  distribution  of  the  Newsletter  to  cover  not  only  all 
groups  identified  within  this  marketing  plan  but  to  the  government  entities  across  the 
board,  DoD,  non-DoD,  and  the  associated  contractor  and  industrial  /  commercial  entities 
who  interact  with  our  market  segment.  The  Newsletter,  although  specific  format  is  yet  to 
be  determined,  shall  focus  on  delivering  special  sections  covering  the  needs,  interest  and 
desires  of  each  of  the  consumer  segments  we  have  identified  (Decision  Makers  - 
GateKeepers  /  middlemen  /  intermediaries  -  Using  Community).  The  approach  may  be 
different  in  addressing  each  group,  for  example;  the  Decision  Makers  section  will  dwell 
on  providing  information,  the  GateKeepers  section  will  focus  on  selling  the  people,  the 
Using  Community  section  will  post  usable  tidbits  of  infonnation  or  post  the  winners  of 
this  months  Most  Valuable  Performer  (MVP)  an  award  sponsored  by  the  SSB  Team, 
[cost  -  one  fifth  of  a  man  year,  $125,000/5  =  $25,000  +  monthly  publication  costs  of  12 
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months  times  5,000  copies  per  month  times  $0.20  per  copy  +  $600  set  up  charge  = 
$12,600,  distribution  costs  not  included,  TBD] 

Activity  2  -  A  Meeting  Place 

All  implementers  regardless  of  focus  have  a  need  to  network  with  other  sharing  in 
the  same  misery,  specifically  for  this  segment  group  who  are  searching  for  leverage  in  the 
pursuit  of  professional  gain  and  acknowledgement.  The  web  site  for  SSB  system  support 
for  the  SSB  community  or  also  known  as  “SSB  Web  Central”  is  maintained  by  the  SSB 
Team  to  initiate  and  promulgate  on-going  discussions  to  enable  the  communities 
networking  efforts.  This  web  site  is  augmented  with  an  “Answer  Garden”  providing  past 
efforts  in  dealing  with  SSB  issues  and  projects,  included  in  this  searchable  data  base  are 
such  things  as  lessons  learned,  Navy  internal  best  practices,  Industry  Best  Practices, 
Transitioning  Planning  documentation,  related  internal  Navy  resources  and  did  we 
mention  the  SSB  Team  Newsletters,  etc.  The  SSB  Team  will  keep  account  of  and  trend 
all  “Cookies”  of  visitors  and  prepare  an  analysis  report  to  share  among  the  staff.  The  SSB 
Team  staff  will  also  monitor  the  site  content  and  participants  comments.  These  efforts  are 
meant  to  craft  the  environment  for  the  COTS  community  to  entice  the  evaluation  and  trial 
of  the  SSB  system  at  minimal  risk,  [cost  -  $40,000  initial  set-up  and  license  fees, 
$10,000  per  year  maintenance  cost,  no  cost  impact  on  the  monitoring  considered  a  part  of 
staff  normal  function] 

3.  Promotion  Plan  for  Group  3,  Using  Community 

The  evaluative  criteria  for  this  group  deals  with  implementation  details  and 
probable  outcomes,  these  criteria  are:  1)  ease  of  use,  2)  visibility  into  the  process,  3)  risk 
identification  and  management,  4)  a  resolution  centric  process  methodology. 

This  group  because  of  the  function  they  perform  is  all  over  the  map  when  it 
comes  to  adopting  of  a  product.  These  people  are  the  true  implementers  of  support 
solutions,  living  with  and  solving,  the  issues  and  challenges  of  the  COTS  products  that 
someone  else  buys  as  a  result  of  a  policy  decision  made  at  an  even  more  removed 
hierarchical  level  within  the  Navy.  This  group  by  necessity  is  a  task  orientated, 
technically  driven,  application  focused  community  of  problem  solvers.  As  identified  in 
the  External  Environment  -  Competitive  forces  -  this  community  has  over  time, 
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developed  its  own  culture  exhibiting  some  specific  characteristics.  Not  all  members  of 
this  community  have  organized  into  well-defined  structures/teams/working  groups  but 
they  too  can  and  do  exhibit  many  of  the  same  characteristics  as  the  well-established 
teams.  The  Using  Community  has  great  influence  with  respect  to  which  alternatives  are 
chosen,  how  they  are  implemented,  and  the  strategic  approach  to  obsolescence  risk 
management.  Depending  on  individual  members  relationship  within  this  community,  the 
marketing  methods  already  identified  (i.e.  conferences,  publications,  Point-Counter-Point 
written  discussions  etc.)  have  probably  provided  exposure  to  the  SSB  system.  This 
community  has  a  need  to  keeping  up  with  the  latest  processes,  methods,  and  tools 
employed  to  support  fielded  systems  and  therefore  will  seek  out  the  kind  of  information 
we  have  placed  in  their  environment.  Driven  by  their  functional  positions,  this 
community  will  be  intensely  interested  in  the  News  Letters  and  SSB  Web  Central,  if  and 
only  if  the  content  of  the  information  addresses  the  actual  implementation  and  problem 
resolution  aspects  of  support. 

Activity  1  -  SSB  Web  Central 

In  an  effort  to  service  the  market  segment,  a  substantial  portion  of  the  SSB  Web 
Central  will  be  set  aside  to  provide  focused  implement  able  solutions,  success  stories, 
detailed  analysis  of  other  PMO  implementation  efforts,  and  tailored  SSB  system 
implementation  planning  with  Lessons  Learned.  Also  posted  and  of  great  interest  will  be 
the  yearly  summary  reports  showing  how  over  time  the  SSB  system  is  performing.  A 
“Discussion  Board”  will  be  provided  and  monitored  to  encourage  networking  and 
information  sharing.  The  Using  Community  section  will  post  usable  tidbits  of 
information  or  post  the  winners  of  this  months  Most  Valuable  Performer  (MVP)  an 
award  sponsored  by  the  SSB  Team.  Current  and  historical  copies  of  the  News  Letter  will 
also  be  available  at  the  site,  [cost  -  as  identified  in  previous  section] 

Activity  2  -  Most  Valuable  Performer  (MVP)  Award 

The  SSB  Team  will  establish  an  award  to  be  given  to  the  implementing 
community  to  recognize  its  outstanding  performers  with  respect  to  SSB  system 
implementation.  The  criteria  for  nomination,  acceptance  and  down  select  shall  be 
developed  by  the  SSB  Team.  However  the  criteria  shall  cover  all  aspects  of  the  processes, 
methods  and  tools,  so  that  singular  parameters  like  reductions  in  LCC  will  not  drive  the 
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awarding  process.  In  this  way  all  implemented  have  a  chance  to  receive  the  award  such 
as  exceptional  tools,  very  effective  implementations  by  small  programs,  innovative 
methods,  etc.  [cost  -  TBD  -  recommendations  by  the  SSB  Team  and  endorsement  by 
management] 

Activity  3  -  Competition  Forces  Addressed 

The  barriers  and  impediments  institutionalized  through  the  existing  cultures 
evident  in  the  User  Community  must  be  addressed  to  assure  maximum  market 
penetration.  Four  major  areas  identified  in  earlier  sections  of  this  plan  need  to  be 
considered:  Resource,  Territorial,  Contractual,  and  Functional  competition.  Each  of  these 
responses  from  individuals  or  groups  will  require  analysis  to  identify  the  root  cause, 
potential  remedies,  and  possible  data  collection  efforts  to  mitigate  the  concerns  that 
provoked  the  response.  The  SSB  Team  will  perform  research,  analysis,  provide 
recommendations,  then  publish  in  a  “White  Paper”  format  the  results  of  the  study.  Some 
of  the  resolutions  will  come  for  logical  analysis  of  data  however  several  identified 
responses  are  behavioral  traits  which  may  require  a  completely  different  approach. 
Regardless  of  the  resolution  method,  the  “White  Paper”  report  will  be  posted  on  SSB 
Web  Central  and  a  discussion  thread  will  be  initiated  on  the  “Discussion  Board”  to  elicit 
feedback  from  the  community.  The  SSB  Team  shall  make  a  special  effort  to  be  involved 
in  the  discussion  thread  to  answer  questions,  collect  data  about  our  customers,  and  help 
break  down  the  competitive  force  structures,  [cost  -  Team  authored  -  $4000  per  report 
generation,  times  4  reports  =  $16,000] 
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